Abend codes and reading dumps

When a step fails on z/OS it doesn't just "crash". It ends with an abend (abnormal end) code, and the job output tells you a lot about why. Reading that output quickly is one of the most valued skills on a support rota.

System and user abends

System abends Sxxx (hex) are issued by z/OS or the hardware: S0C7, S806, SB37.
User abends Unnnn (decimal) are issued by software: Language Environment (LE) uses U4038 for severe errors, and your own program can abend on purpose (for example with CALL 'CEE3ABD') when it finds a condition it must not continue past.

An abend is different from a return code. RETURN-CODE 8 is a normal end that says "I finished, but it went badly"; later steps can test it with COND. An abend stops the step and, unless COND=EVEN or COND=ONLY, flushes the rest of the job.

Codes worth knowing by heart

Code	Meaning	Usual COBOL cause
`S0C7`	data exception	invalid packed/zoned data
`S0C4`	protection exception	subscript out of range, bad `LINKAGE` address
`S0CB`	decimal divide exception	division by zero
`S0C1`	operation exception	branch to an invalid address, e.g. an unresolved `CALL`
`S806`	module not found	wrong `PGM=`, missing `STEPLIB`
`S322`	CPU time exceeded	an endless loop
`SB37` `SD37` `SE37`	out of space	output bigger than its `SPACE`
`S013`	open conflict	`LRECL`/`RECFM` differ from the FD
`S913`	security violation	no RACF access to a dataset
`S222`	cancelled	an operator or a job-time limit killed it
`U4038`	LE severe error	often an `OPEN` failure with no `FILE STATUS`

Where to look

JESMSGLG / JESYSMSG: the job log. IEF450I ... ABEND=S0C7, plus allocation messages (IEF237I) and dataset dispositions.
SYSOUT: your own DISPLAY lines, showing how far the program got.
CEEDUMP: LE's formatted dump. The traceback at the top is the gold: the failing program, statement number and the call chain.

CEE3207S The system detected a data exception (System Completion Code=0C7).
  Traceback:
    Program Unit  Entry     Statement  Status
    CLMCALC       CLMCALC        1482  Exception
    CLMPROC       CLMPROC         317  Call

CLMCALC failed at statement 1482, called from CLMPROC statement 317. Open the compile listing for that version of the program, find statement 1482, list the numeric fields it uses, and check each one's bytes. If only an offset is given (+00000A4C), the listing's offset map (compiler option LIST or OFFSET) gives the statement.

Tools like Abend-AID or IBM Fault Analyzer do much of this for you and even show the field values, but they present the same facts.

Try it here

The job simulator imitates a few of these. Here is a classic: a step whose JCL forgot the CUSTIN DD statement. Run the program with no input dataset:

       IDENTIFICATION DIVISION.
       PROGRAM-ID. ABENDME.
       ENVIRONMENT DIVISION.
       INPUT-OUTPUT SECTION.
       FILE-CONTROL.
           SELECT CUST-FILE ASSIGN TO CUSTIN
               ORGANIZATION IS LINE SEQUENTIAL.
       DATA DIVISION.
       FILE SECTION.
       FD  CUST-FILE.
       01  CUST-REC             PIC X(80).
       PROCEDURE DIVISION.
           DISPLAY "ABENDME: OPENING CUSTIN"
           OPEN INPUT CUST-FILE
           DISPLAY "ABENDME: OPEN OK"
           CLOSE CUST-FILE
           STOP RUN.

ABENDME: OPENING CUSTIN
libcob: error: file does not exist (status = 35) for file CUST-FILE ('CUSTIN')

The second DISPLAY never appears, and there's no FILE STATUS to check, so the runtime ends the program. Run as a job step with no CUSTIN DD, the simulator reports ABEND U4038 and flushes the later steps, just like z/OS, where Enterprise COBOL issues IGZ0035S There was an unsuccessful OPEN ... The status code was 35 and LE abends U4038. A missing program gives S806 and an endless loop S322.

On the job

A good first message to the team about a failed job reads like: "CLMEOD step PROCESS abended S0C7 at CLMCALC statement 1482 (COMPUTE WS-PAYABLE). CLM-AMOUNT in record 20417 of CLAIMS.DAILY is spaces. Upstream file issue, suggest rerun after correction." Code, place, field, record, cause, next step.