Moving '00000000' to date field

[nxm150]

Our leader decided to keep our date fields as PIC X(8) instead of my recommended PIC 9(8). We are suppose to initialize some of the date fields for privacy reasons. So when I initialize the date it became spaces (obviously) instead of zeroes. My tech leader then kicked himself for not using PIC 9 field and said for the time being just move '00000000' to the date field. Would there be any problems down the line that would present itself if we took this band aid route instead of going back and changing the copybook?

 

[razalas]

77 CHAR-DATE PIC X(8).
77 NUM-DATE  PIC 9(8).

MOVE ZEROS TO CHAR-DATE
MOVE ZEROS TO NUM-DATE

Both move statements above will result in zeros in the receiving field since the compiler will use the appropriate literal type for the sending field depending on the type of the receiving field.

"Code what you mean,
and mean what you code!
But by all means post your code!"

Razalas

 

[nxm150]

So, in your above example

MOVE ZEROS TO CHAR-DATE

is the same as

MOVE '00000000' TO CHAR-DATE?

 

[confusedlady]

When I first started at this shop, I had to learn to do exactly that (move zeros and not use initialize) when making any changes to a program, since this was exactly my situation. And it didn't occur to me that someone would define as pic x field. Until after problems. Live and learn, right?

 

[razalas]

It is better if you code your numeric fields as PIC 9's instead of PIC X. Mainly so that those who come after you won't have as much guessing to do about the nature of the field in question.

Of course, it also makes the use of the INITIALIZE verb more meaningful (which personally I prefer to use whenever possible).

But in the case where you are confronted with a PIC X field that is supposed to contain numeric data, the MOVE ZEROS has the advantage over MOVE '0000' in that it guarantees that the field will be entirely filled with zeros. And it also makes the code more "readable" IMHO.

"Code what you mean,
and mean what you code!
But by all means post your code!"

Razalas

 

[WMK]

It is even possible to initialize alphanumeric fields to zeroes - with the initialize statement, e.g.

Initialize Group-Field
Replacing alphanumeric by zeroes


Or if you have some alphanumeric items in the group that you want to be spaces, but some you want to be zeroes, then

Initialize field-1 field2
replacing alphanumeric by spaces.
Initialize field4 field 5 *> devaults to spaces.

I am *not* saying this is any "better" than a simple MOVE statement, but it is legal.

Bill Klein

 

[wahlers]

Your remark:
"Our leader decided to keep our date fields as PIC X(8) instead of my recommended PIC 9(8)."

This might(!) have been the reason:

Strictly speaking your leader is correct by saying that the contents is not a number.
Because you can do arithmetic with a number (like add, multiply, subtract, and so on...)
And arithmetic has no meaning with dates.
I mean, tell me the result of the following:

MULTIPLY date1 BY date2 GIVING someResult

The someResult is meaningless!
Of course you can use a subset of the arithmetic functions such as:

ADD 1 TO date1

With a little bit of luck you get another valid date (though not always!).

You may argue that date is a number because you can add and subtract days from it albeit not in the normal decimal fashion (ignoring the fact that add and subtract are the only legel arithmetic functions you can use).

It is more clear with personelNumber.
The contents of personel number is not a number but just a identification field consisting of digits only.
In this case any and all arithmetic functions are meaningless.

The only reason why we use digits only instead other characters is for sake of (database) storage.
Think about, in the real world everybody knows Mr. Smith but nobody knows 123456789 (which is the SSN of mister Smith).
It is only when Mr. Smith has to do official business that he will pass his SSN (and thus making him a unique Mr. Smith among thousends of other Mr. Smith's).

Still don't believe!
Then I suggest to change all email addresses to the unique SSN and see if this works easier from a human perspective.


Regards, Wim Ahlers.

 

[webrabbit]

I disagree. Perhaps one does not do arithmetic on SSN's once they are assigned, but I am sure that the Social Security Service does when generating them. Also, some numeric codes (such as UPC's) have check digits built into them, and one does arithmetic to verify the check digit.

In the system I sell, the part numbers are numeric, and the program does arithmatic to generate them.

Also, SUBTRACT DATE-1 FROM DATE-2 GIVING TIME-LAPSE does make sense, even though strictly speaking it won't work in COBOL (it does in languages that have a Date type defined).

 

[3gm]

Defining date fields has always been a bit of a headache in COBOL. As a general rule, I've always defined dates as alphanumeric and initialized them to spaces. If I've needed to do arithmetic on them (unlikely, but consider the second post in the recent thread about tricks in COBOL thread209-839069), I've redefined them as PIC 9 and done appropriate numeric testing before using them as such. I think this is a reasonable approach considering that when a date is optional, users seem to prefer it be blank on reports and screens rather than zeros (although BWZ might solve this issue).

I've worked on systems where all the internal dates were serial (i.e. days since some arbitrary date such as 1/1/1900). That has some advantages, especially in comparing and calculating with dates, but how do you represent a date that is "empty"? I suppose if one bases the zero date sufficiently far in the past, one may be able to consider the zero date as "empty". However, that's not a very general solution. Also, it can be very painful to work with dates in their raw form such as in a file dump.

Modern databases deal with this problem by having a date datatype and a distinguished null value.

IBM's ILE extensions seem to be an attempt to improve date handling in COBOL, but I have too little experience with them to voice an opinion.

Perhaps Bill Klein or others can shed light on anything in the new standard that helps here?

Regards.

Glenn

 

[stevexff]

I've used the LE/370 date functions quite a bit, and they use a similar scheme to most others, holding the date as a positive or negative offset from a particular date. In this case Friday 14 October 1582 (something to do with the Pope formalising the calendar, they are obviously very scholarly at IBM ) This allows you to convert dates to numbers (CEEDAYS) and back again (CEEDATE). They also have similar functions for timestamps, holding the number of seconds since the same date.

This gives you all the arithmetic you could need for dates, intervals etc., as well as having customisable date formats. The functions are callable from other HLLs, and even assembler, and so can give you a consistent date formatting scheme across applications if required. But as with all IBM stuff, its flexibility comes at the expense of complexity, so you might want to write a little wrapper module to hide it from your APs...

Steve

 

[WMK]

Sorry for not noticing the question (to me) earlier.

The ISO 2002 Standard *does* include

TEST-DATE
TEST-DAY

intrinsic functions to determine if a DATE/DAY field is or is not "valid" (and hence elligible for a "clean" usage of INTEGER-OF-DATE/DAY.

If there is an error, the returned value is "medium" helpful in figuring out what was wrong.

Bill Klein