S0C4 — protection / addressing exception
The program touched storage it is not allowed to use — often a subscript out of range, a bad parameter list or a closed file.
What happened
The step abends with system completion code 0C4. A reason code comes with it, and in CICS the same problem appears as transaction abend ASRA.
IEA995I SYMPTOM DUMP OUTPUT SYSTEM COMPLETION CODE=0C4 REASON CODE=00000004 PSW AT TIME OF ERROR 078D1000 9A3C21F6 ILC 6 INTC 04 ACTIVE LOAD MODULE ADDRESS=1A3C1000 OFFSET=000011F6 NAME=CUSTUPD CEE3204S The system detected a protection exception (System Completion Code=0C4). IEF450I CUSTJOB1 STEP030 - ABEND=S0C4 U0000 REASON=00000004
What it means
An instruction used an address the program has no right to. Either the storage belongs to someone else and is protected, or the address does not exist in the address space at all. The reason code tells you which: 4 is a protection exception; 10 and 11 mean the address was not in valid, mapped storage.
In COBOL this almost always means a field was addressed through a bad base: a runaway subscript, a LINKAGE SECTION item with no real data behind it, or a pointer that was never set.
Typical causes
- A subscript or index ran past the end of an OCCURS table.
- Reference modification with a bad start or length.
- A CALL parameter list that does not match the called program's LINKAGE SECTION, in number or size of parameters.
- Using a record area of a file that is not open — before OPEN or after CLOSE.
- A pointer or address that was never set.
- In CICS, using DFHCOMMAREA when EIBCALEN is zero.
Symptoms
The failure may be random or move around between runs, because it depends on what lies in storage beyond your data. That differs from S0C7, which repeats on the same bad value. Writing past the end of a table corrupts whatever follows, so the abend can occur much later, in unrelated code.
Where to look
- JESMSGLG: completion code, reason code, PSW and offset.
- CEEDUMP: traceback showing the call chain and which program was active.
- The compile listing (LIST, or OFFSET on older compilers) for the exact module that ran.
- For CICS, the transaction dump and CICS messages in the region log.
How to diagnose
- Note the completion and reason codes, the module and the offset.
- Check the traceback: was the failing code in your program, a called program or a system routine?
- Map the offset to a statement and look at every subscript, pointer and linkage item it uses.
- Check every CALL against the called program's LINKAGE SECTION, field by field.
- Check whether the file was open at the time.
- Recompile in test with SSRANGE and rerun; an out-of-range subscript then gives a clear run-time message instead of a corruption.
How to fix
Fix the code: bound the subscript, correct the parameter list, open the file before using its record area, or test EIBCALEN before addressing the commarea. Recompile and relink both caller and called program if an interface changed. Rerun only after checking whether earlier steps or partial updates need restoring.
How to prevent
- Check table bounds explicitly before using a subscript in production code.
- Keep parameter layouts in shared copybooks so caller and called program stay in step.
- Use SSRANGE in test builds.
- Code CICS programs to check EIBCALEN on every entry.
Production considerations
Interview question
Why might the line where an S0C4 occurs not be the line that caused it?
Stuck on something else?
Ask the community or search the full course.