'Vital' COBOL and ABEND Handling

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...=so
urce>
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
ws, 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