Aborting a Program
When a program encounters a fatal error, it should issue one or more
appropriate messages and then abort. There are two main ways to abort:
abend with a dump, or exit with a non-zero return code.
In most cases, you don't want to catalog the files produced by an
aborted job step. The way you control cataloging depends on the way
you abort.
Abending
In JOCKEY, the prevailing practice is to abend with a dump. An abend
is ugly, and the dump takes up a lot of space on the sysout (usually
without being useful). However, an abend is almost certain to get
somebody's attention.
To avoid cataloging an output file from an abending job step, code
DISP=(,CATLG,DELETE) on the DD statement.
Non-Zero Return Codes
Some shops prefer to exit with a non-zero return code such as 16.
This approach reserves abends for situations where the resulting dump
is likely to be useful: namely, run-time exceptions such as S0C7's and
S0C4's.
The disadvantage is that you have to check the return code in order
to control subsequent job steps, using COND clauses on the EXEC
statements.
You can also use the return code to control the cataloging of files.
When you create a file, don't catalog it immediately. Give it a
disposition of (,PASS,DELETE). A later job step, usually an IEFBR14 at
the end of the job, catalogs anything needing to be cataloged. A COND
clause prevents the cataloging if any previous job step has had an
unsuitable return code.
With this approach, no one has to clean up after an aborted job,
because nothing was cataloged.
A Hybrid Approach
It would be possible to use abends to abort, and also use an IEFBR14 at
the end of the job to catalog files. You can get people's attention
with an abend, and also not have to clean anything up.
COBOL Home
COBOL Style Forum