S0E0: Access register or linkage stack program check

What it means

The 0Cx codes cover the classic program checks, from operation exceptions to floating-point divide. The processor can raise many more, and z/OS reports a group of them as system completion code 0E0. The reason code carries the program interruption code from the hardware, so the same reason appears in IEA995I and in the INTC field of the PSW information.

The interruption codes in this group come from features used by system and middleware code rather than ordinary applications.

• Access-register translation. In access register (AR) mode, each general register used as a base is paired with an access register that holds an ALET, which selects the address space or data space to use. Reason 28 means the ALET has nonzero bits in positions that must be zero. Other codes report an ALET that points to a missing or reused access list entry, or an authority failure.
• The linkage stack, used by PC and BAKR to save state.
• A few hexadecimal floating-point cases, such as a square root of a negative number.

Not every newer program check lands here. Failures of the PC instruction itself, such as a PC number that isn't defined, have their own completion code (0D6), and translation exceptions for virtual addresses are reported as S0C4.

Programs written in COBOL or PL/I don't run in AR mode or use these instructions directly. When a batch job ends with S0E0, the failing code is usually authorized assembler, a vendor product or a z/OS component working on the job's behalf.

Common causes

• A program switched into AR mode (SAC 512) while an access register still held a leftover value, so a base register paired with that access register used a bad ALET. IBM has fixed this kind of bug in several products, and it usually shows up as reason 28.
• An ALET was used after its access list entry had been deleted, for example after the data space it pointed to was deleted.
• A routine reached through PC or BAKR damaged or mismatched its linkage stack entries, for example by issuing EREG or PR when no matching entry was there.
• A program used the linkage stack more deeply than it allows, for example through recursive PC or BAKR calls that never return, so the stack ran out of room.
• A diagnostic setting that fills unused registers with non-zero values exposed code that wrongly assumes its access registers start at zero.

How to find the problem

1. Find the IEA995I symptom dump in the job log or system log. The REASON CODE is the program interruption code. Note it, along with the load module name and the offset.
2. Look up that interruption code in z/OS MVS System Codes under 0E0, or in z/Architecture Principles of Operation, to see exactly which exception it is.
3. For reason codes 28 through 2D, the access-register group, look at the access registers in the dump (SYSUDUMP, SYSMDUMP or SVC dump). The access register paired with the failing base register holds the bad ALET.
4. Check the module name. If it belongs to IBM or a vendor, search their support site for ABEND0E0 together with the reason code and the module name.

How to fix it

• Clear the access registers, for example with LAM from a list of zeros, or set them deliberately with LAM or CPYA, before switching into AR mode.
• Make sure an ALET is still valid before using it, and delete access list entries only after all users are done with them.
• Pair every BAKR or stacking PC with exactly one PR on every path, and avoid unbounded recursion through the linkage stack.
• For IBM or vendor code, apply the fix the supplier provides. If a diagnostic setting exposed the bug, you can turn that setting off while you wait for the fix.

What it looks like

IEA995I SYMPTOM DUMP OUTPUT
  SYSTEM COMPLETION CODE=0E0  REASON CODE=00000028
IEF450I EXTRACT1 STEP010 - ABEND=S0E0 U0000 REASON=00000028

Technical reviewer: Albert Joseph, WND Software.

Last reviewed 2026-10-18 by the WND Software team. Written in our own words. For the full reference, check IBM’s z/OS documentation for your release.