| docdwarf@panix.com 2005-06-08, 8:55 pm |
|
Folks may wonder why I am, at times, so... gentle when it comes to matters
of coding style. A situation that I ran into today might help demonstrate
this.
The project I was working on went live - that's a whole other story - and
to keep me busy I've been asked to look into ABEND handling by means of
the /USRHDLR facilities. This is on an IBM mainframe; the newer versions
of the operating system allow for a condition which might have caused a
program to ABnormally END to recover more-or-less gracefully. I coded up
a sample to which Mr Klein had directed me (details might be found in
<http://groups-beta.google.com/group...bc?dmode=source>
for those who are interested) and began working with a copy of a
production program.
The program contained the following 'common code', as do many other
programs here:
01 FORCED-ABEND VALUE SPACES PIC XX.
01 FILLER REDEFINES FORCED-ABEND.
03 ABORT-1 PIC 9.
03 ABORT-2 PIC 9.
....
9900-ABORT-PROGRAM.
DISPLAY STAR-LINE.
DISPLAY STAR-LINE.
DISPLAY FATAL-ERR.
DISPLAY FATAL-ERR.
DISPLAY FATAL-ERR.
DISPLAY STAR-LINE.
DISPLAY STAR-LINE.
GO TO 9901-ERR-1 9902-ERR-2 9903-ERR-3 9904-ERR-4 9905-ERR-5
DEPENDING ON ERR-RETN.
GO TO 9998-ABORT.
9901-ERR-1.
DISPLAY E-EDIT-CTRL-REC-KEY-CD
' ALREADY EXISTS ON CTRLFILE; FILE-STAT = '
FILE-STAT.
GO TO 9998-ABORT.
9902-ERR-2.
DISPLAY E-EDIT-CTRL-REC-KEY-CD
' TO BE UPDATED DOES NOT EXIST ON CTRLFILE; FILE-STAT = '
FILE-STAT.
GO TO 9998-ABORT.
9903-ERR-3.
DISPLAY 'NO DATECTRL RECORD FOUND'.
GO TO 9998-ABORT.
9904-ERR-4.
GO TO 9998-ABORT.
9905-ERR-5.
GO TO 9998-ABORT.
9998-ABORT.
DISPLAY 'THIS PROGRAM WILL ABORT'.
DISPLAY STAR-LINE.
DISPLAY STAR-LINE.
COMPUTE ABORT-1 EQUAL ABORT-1 / ABORT-2.
9999-EXIT.
EXIT.
.... and I made use of this. (When I first saw this I mentioned to my tech
lead that this technique was rather... hoary; his response was 'Yep, but
everyone here's used to it and it works... leave it alone.') I found a
suitable spot in the program - after the READ of the driver-file - and
coded a simple PERFORM 9900-ABORT-PROGRAM THRU 9999-EXIT; I then made a
sample driver-file containing three records and let 'er rip.
Things ran well; even though the non-numeric COMPUTE was encountered three
times the job terminated normally... but it was odd. Instead of three
dumps there were six, two for each record... and this made no sense. I
stuffed some debugging code into the TOPHDLR routine and, sure enough, it
was being called six times, not three... and then it hit me.
I zeroed in upon the statement:
GO TO 9901-ERR-1 9902-ERR-2 9903-ERR-3 9904-ERR-4 9905-ERR-5
DEPENDING ON ERR-RETN.
.... and checked WORKING-STORAGE... and found:
01 ERR-RETN PIC 99.
.... and there you have it. ERR-RETN contained... air, it was non-numeric;
the CEEDUMP listing showed:
01 ERR-RETN 99 DISP
.... and when the GO TO DEPENDING ON tried to use it another ABEND was
generated. I changed my test-code to:
MOVE 4 TO ERR-RETN
PERFORM 9900-ABORT-PROGRAM THRU 9999-EXIT
.... and got the three-calls-to-CEEDUMP I expected, each of which showed:
01 ERR-RETN 99 DISP 04
.... and the other... stuff I was working on.
'Vital' code? This stuff generates about 65,000 paychecks every two
w s, among other Payroll/Personnel functions... and there's a bunch of
it out there.
(I just checked... it contains 20 GO TOs, 2 GO TO DEPENDING ONs and 46
NEXT SENTENCEs... and 3 END-IFs... quelle fromage... errrrr, d'hommage...
errrr, fettucine.)
DD
|