COBOL TIPS #20
by
Shawn M. Gordon
President S.M.Gordon & Associates
The date debate continues it seems. Earlier this year I showed a macro for formatting a date variable in YYMMDD format to a MM/DD/YY display format, using the following code;
01 IN-DATE PIC X(06) VALUE SPACES.
01 OUT-DATE PIC X(08) VALUE SPACES.
$DEFINE %FMTDATE=
MOVE "/" TO !2(3:1)
!2(6:1)
MOVE !1(1:2) TO !2(7:2)
MOVE !1(3:2) TO !2(1:2)
MOVE !1(5:2) TO !2(4:2)#
%FMTDATE(IN-DATE#,OUT-DATE#).
Then Dennis Dunkman wrote me about my “painful” method, and supplied us with a nifty little trick to do the date conversion, as follows;
05 DATE-ORD PIC S9(9) COMP.
05 PRNT-DATE-ORD PIC 99/99/99.
COMPUTE PRNT-DATE-ORD = DATE-ORD * 100.0001.
Now I thought this was a pretty neat trick, it had a couple of limitiations, like requiring that the source and destination dates be numeric, but overall a very innovative solution. Now one of my 10’s and 10’s of avid readers decided to see what the CPU impact was between using the two methods, and this is what Duane Percox found (I hope I spelled his name right);
A followup to your response regarding the date conversion routine.
I don’t agree with your assessment that the compute would be equiv to a set of moves. This is because of these factors:
1. The compute has a decimal point which will cause lots of overhead
2. With reference modification you can do moves that are in essence
byte block moves with no type checking.
I wrote a sample app and did some timing using proctime. Here are the results:
loop size compute ref-mod 100 2 0 1000 14 1 3000 42 3 5000 69 6 50000 697 50 999999 13,925 1,001
These times are in milliseconds. As you can see the compute is approx. 13+ times more expensive.
sample ref-mod code:
move date-mmddyy(5:2) to date-yymmdd(1:2).
move date-mmddyy(1:2) to date-yymmdd(3:2).
mmove date-mmddyy(3:2) to date-yymmdd(5:2).
So, it might be easier for the programmer, but it doesn’t appear that using compute…. is easier for the computer!
The timing loops operated on the date: 063095 each time, both loops in the same program. First the compute, then the moves.
Duane’s test was run on a 937lx, 72mb, development only system (< 10 users) I want to thank Duane for taking the time to check into the details, it's people like him that keep us all on our toes. All the feedback has been great, but I would like to make one point, I was talking to one of the other columnists for Interact that had experienced the same thing. We get questions from readers fairly often, and we love to hear from everyone, and help where we can, but a 'Thank You' or acknowledgment of the help is always appreciated. We often spend a decent little chunk of time looking into your questions to answer them, and getting no response afterward is a little frustrating. Anyway, last month I promised to write more about using function keys this month, but with the new, streamlined version of Interact I find that I run out of space quicker than I anticipate. So I am going to cover Function Keys next month. Also I am in the midst of reviewing a product called EZ-C, which use to just be a tool for the C programmer, but has recently been enhanced to include COBOL. It looks pretty interesting at this point, and the review should be out in November or December. By the time this issue hits the stands my first son will be about 1 month old. So this column is really going to drop off significantly in the next couple of months. If anyone at SIG-COBOL would like to work with me on keeping it going, give me a shout. Thanks again for the support.