COBOL TIPS #16
by
Shawn M. Gordon
President S.M.Gordon & Associates
Well my ‘state of the union’ column seemed to get more interest than most of the stuff I have been writing. I got some corrections from folks as well as ideas, and new information. So I am going to publish some of what I found out and share it with you.
My first bit of information comes from Joe Geiser, the able bodied Client/Server columnist for Interact magazine. I was talking about a COBOL type product that was similar to Visual Basic that sold for a few hundred dollars. Joe let me know about CA-Realia from Computer Associates that is apparantly an object oriented version of COBOL that “does Windows” which Joe says has a street price of about $800. Also there is the MicroFocus COBOL WorkBench (which we sort of talked about last month with their COOL implementation) that Joe says is more robust than the CA-Realia product, and has a street price of about $1,000. I want to thank Joe for the information, and also mention that Joe has been a great source of information for Windows programming in general, he really knows his stuff, make sure to check out his column.
I got this next note from Dennis Dunkman, and I enjoyed how he worded it, so I thought I would share it in it’s entirety.
I saw your painful method for converting a date from yymmdd to mm/dd/yy in the December 94 Interact. I thought you might be interested in a slightly simpler, if unobvious way to do the same thing. (See attached.)
(Painful? It could be worse: I’ve seen programs that take HP’s CURRENT-DATE register and move the day, month and year to get a yymmdd date. Why didn’t they just ACCEPT … FROM DATE to begin with?)
I don’t recall where Steve originally got the algorithm. All I remember is that he got it somewhere else. But it’s kind of neat. One thing I haven’t tried is using the “de-editing” ability of Cobol-85 to convert a 99/99/99 date
into a PIC 9(6) field. I assume it should work.
T E C H N I C A L T I P
AUTHOR : Steve Heininger DATE : 85/06/26
CLASS : COBOL
TOPIC : Date reformat routine
UNIX NAME : cobol.0004
TIP: A date in the format MMDDYY can be easily changed to a
YYMMDD format as follows:
01 DATE-MMDDYY PIC 9(6).
01 DATE-YYMMDD PIC 9(6).
COMPUTE DATE-YYMMDD = DATE-MMDDYY * 10000.01.
After decimal alignment and truncation the remaining six digits
will be the date in YYMMDD format.
The calculation can go the other way also by:
COMPUTE DATE-MMDDYY = DATE-YYMMDD * 100.0001.
As simple as this seems, it really does work!
RESTRICTIONS: None
T E C H N I C A L T I P
AUTHOR : Dennis Dunkman DATE : 92/04/23
CLASS : COBOL NUMBER: 28
TOPIC : Date reformat routine revisited
UNIX NAME : cobol.0028
TIP: Steve’s date reformat routine (Cobol Tech Tip #4) is one of the most massively useful algorithms around. However, I have seen it used in ways that indicate that some of you don’t understand how it works. I’ll try to rectify that here.
The important point to remember is that the reason the calculations work is that they rely on truncation of the result when it is moved to the destination field. For example, to convert 920423 to 042392, the calculation is
920423 * 100.0001 = 92042392.0423
which, when truncated by moving to a PIC 9(6) field results in
042392.
The important thing to remember is that the RESULT FIELD MUST BE A SIX DIGIT NUMERIC FIELD. This means 9(6), S9(6) COMP and 99/99/99 are all valid. The source field may be any valid numeric field of any length.
For example, converting a date in a data set to a formatted date on a print line can be done in one statement:
05 DATE-ORD PIC S9(9) COMP.
05 PRNT-DATE-ORD PIC 99/99/99.
COMPUTE PRNT-DATE-ORD = DATE-ORD * 100.0001.
Note that there is no need to move DATE-ORD to a PIC 9(6) field or to calculate into a PIC 9(6) field.
Note that the reverse would not work:
COMPUTE DATE-ORD = PRNT-DATE-ORD * 10000.01
would result in 423920423 in DATE-ORD.
Now that we’re nearing the turn of the century, four-digit years should be coming into use. The following calculations may be used for these:
COMPUTE DATE-MMDDYYYY = DATE-YYYYMMDD * 10000.0001
COMPUTE DATE-YYYYMMDD = DATE-MMDDYYYY * 10000.0001
In this case, the result field must be 8 digits long. Note that the conversion factor isthe same no matter which way you go (10000.0001).
RESTRICTIONS: None
———————-
Ok, I am back now. I must say that I never would have though of this method of formatting a date, and it does work, I tried it out. The only disadvantage to this method is if you won’t always have a date and you want the field to
be blank in that case. I want to thank Dennis again for the great tip, I love all this new information I am getting.
Our last piece of mail comes once again from Rick Gilligan who has contributed some great ideas to this column in the past. Rick’s note however is a warning about a tip I published from another reader. Here again I will reprint his
note.
Shawn, the example from John, while ingenious (I _do_ like it), is also seriously flawed (darn!).
I’m talking about the overlapped move which removed leading spaces…
ANSI COBOL does not define the result of this operation. Also, I believe that the COBOL optimizer may emit code which would fail for an overlapped move.
To quote from the HP COBOL manual:
Overlapping Operands and Incompatible Data
When a sending and a receiving data item in an arithmetic statement or an INSPECT, MOVE, SET, STRING or UNSTRING statement share a part of their storage areas, the result of the execution of such a statement is undefined.
It’s on page 8-46 in the July 91 edition.
Different compilers may implement moves differently… especially if they are RISC machines which may use a word load and store to and from registers for the main part of the move, and a load and store with some masks or shifts for the partial word at the beginning and end of the move.
This is a bit dangerous to count on…
Darn!
Thanks for all the work you put in writing the column.
Rick Gilligan
———————–
I agree with Rick here, darn, I had rewritten some of my deblanking routines to use the method that John had supplied. It would be nice if we had some of the verbs that are in many implementations of BASIC for stripping leading characters and other such tools instead of having to come up with strange work-arounds. Thanks Rick for the warning.
That pretty much wraps it up this time around, I want to thank everyone again for helping to keep COBOL and this column alive.