S0C5: Addressing exception
An S0C5 abend means an instruction used an address that lies outside the storage installed or configured on the machine. On current z/OS systems most bad addresses in application programs are reported as S0C4 instead, so S0C5 is uncommon.
Other names for this code
Also written as 0C5, SOC5, abend 0C5, system abend 0C5, S0C5-5, addressing exception.
What it means
When the processor raises an addressing exception, program interruption code 5, z/OS ends the task with system completion code 0C5 and reason code 5. The exception means the storage address the processor finally arrived at is beyond the storage that actually exists.
Programs on z/OS normally run with dynamic address translation (DAT), so every address they use is virtual and the processor maps it to real storage through tables that z/OS maintains. If a program uses a virtual address that z/OS hasn't backed with storage, the processor raises a translation exception, and z/OS reports that as S0C4 with reason code 10 or 11. That is why a bad pointer in a COBOL or PL/I program today usually ends in S0C4, not S0C5.
Older references list S0C5 as a common abend because earlier systems ran more code against real addresses, where a bad pointer could reach past the end of storage. On a current system, treat S0C5 in the same way as an S0C4. The root cause is still an address the program should never have used. If the failing code is part of z/OS or a vendor product running authorized, collect the dump and report it.
Common causes
- A pointer, base register or address constant holds a value that was never set, was overwritten, or was truncated.
- The caller and the called program disagree about the parameter list, so a data field is used as an address.
- A table subscript or index ran far beyond the table, and the computed address landed outside storage.
- Authorized or system code that works with real addresses used a bad one. This is outside the control of an application programmer and needs IBM or vendor support.
How to find the problem
- Find CEE3205S (Language Environment) or the IEA995I symptom dump in the job log. Note the PSW address, the ILC, and the load module name and offset.
- Match the offset to the compiler listing (LIST or OFFSET option) to find the statement, then decode the instruction to see which registers formed the address.
- Read those registers in the dump or with a tool such as Fault Analyzer or Abend-AID, and trace back to where the bad value was set.
- If the failing module isn't yours, check SYS1.LOGREC and the system log for related errors, and search IBM support for the module name and ABEND0C5.
How to fix it
- Set every pointer and LINKAGE SECTION address before using it, and stop using an address once its storage has been freed.
- Make caller and called program parameter lists match, and recompile both after a copybook change.
- Add range checks for subscripts, or compile with SSRANGE in test.
- For IBM or vendor code, apply the fix the supplier provides, or open a case with the dump and the logrec record.
What it looks like
IEA995I SYMPTOM DUMP OUTPUT SYSTEM COMPLETION CODE=0C5 REASON CODE=00000005 IEF450I CLMRUN04 STEP020 - ABEND=S0C5 U0000 REASON=00000005
IBM documentation
IBM z/OS: 0Cx program interruptions. Use the documentation for your installed release.
Related codes
Questions
What is the difference between S0C4 and S0C5?
S0C4 covers protection and translation exceptions, which is how z/OS reports most bad virtual addresses. S0C5 means the address ended up beyond the storage that exists. The usual root cause, a bad pointer, is the same.
Why do old manuals call S0C5 common?
Earlier systems ran more code against real storage, where a bad address could easily run past the end. With virtual storage, the same mistake usually raises a translation exception and shows up as S0C4.
How does S0C5 show up in CICS?
As the transaction abend ASRA. The transaction dump shows the program check with interrupt code 5.