S0C7 — data exception

What happened

The batch step ends abnormally. The job log shows a system completion code of 0C7 and a symptom dump pointing at your program.

IEA995I SYMPTOM DUMP OUTPUT
SYSTEM COMPLETION CODE=0C7  REASON CODE=00000007
PSW AT TIME OF ERROR  078D1000   9A2B4C1E  ILC 6  INTC 07
ACTIVE LOAD MODULE  ADDRESS=1A2B3000  OFFSET=00000C1E
NAME=PAYCALC
CEE3207S The system detected a data exception (System Completion Code=0C7).
IEF450I PAYJOB01 STEP020 - ABEND=S0C7 U0000 REASON=00000007

What it means

The processor tried to run a decimal instruction — add, subtract, multiply, divide, compare or convert — on a field that is not valid packed decimal or valid zoned decimal. It refuses to guess, so the program stops at that instruction.

A valid packed field holds digits 0–9 in every nibble except the last, which must be a sign (usually C, D or F). A valid zoned (USAGE DISPLAY) numeric holds X'F0'–X'F9', with a sign in the zone of the last byte. Spaces (X'40') and low-values (X'00') fail both tests.

Typical causes

• A numeric field was never initialised and contains spaces or low-values.
• A group item or alphanumeric field was moved into a numeric field, copying non-digit bytes as-is.
• The input record has a different layout from the one the program expects — a header, a trailer, a short record or an old Copybook version.
• A file arrived from another system with a different encoding, or with packed fields damaged by a text-mode transfer.
• A REDEFINES treats character data as numeric.
• A table entry beyond the loaded rows was used, so the program read uninitialised storage.

Symptoms

The failure is data-dependent: the same program ran yesterday and the code has not changed. Rerunning with the same input fails at the same record. That distinguishes it from S0C4, which is about addresses, not values. Note that Enterprise COBOL options such as NUMPROC, and in Enterprise COBOL 6 the ZONEDATA option, affect how invalid zoned data is treated, so some bad data may produce wrong results rather than an abend.

Where to look

• JESMSGLG and JESYSMSG in SDSF: the completion code, the symptom dump and the offset.
• SYSOUT and CEEDUMP: the Language Environment message and traceback, with statement numbers if the program was compiled with TEST.
• The compile listing: the LIST output (or OFFSET on older compilers) maps the offset to a statement; the MAP output shows field layouts.
• The input file itself, browsed with HEX ON.

How to diagnose

1. Confirm the code is 0C7 and note the program name and offset.
2. Map the offset to the COBOL statement using the listing for the exact load module that ran.
3. Identify every numeric field used by that statement.
4. Find which record was being processed — a DISPLAY of the key, a record count, or the CEEDUMP data values.
5. Browse that record with HEX ON and check the suspect field byte by byte.
6. Trace back to where the field was last set: a READ, a MOVE, an initialisation or a called program.

How to fix

Correct the data or the code, depending on the root cause. If one bad record arrived, have the data owner correct or remove it and keep evidence of what you changed. If the program let a bad value through, fix it to validate and reject. Rerun the step from the top only after checking its outputs are recreated cleanly, not appended to.

How to prevent

• Test input with IF field IS NUMERIC before arithmetic.
• Use INITIALIZE for working storage instead of relying on VALUE clauses in called programs.
• Reject and report bad records to an error file rather than abending on them.
• DISPLAY the current key at checkpoints — it turns a mystery into a two-minute job.
• Agree file layouts and encodings formally with every sending system.

Production considerations

Interview question

A batch COBOL job abends with S0C7. How do you find the cause?