S0C3: Execute exception

What it means

The EXECUTE instruction (EX) runs one other instruction, called the target, that sits somewhere else in storage. Before running it, the processor ORs bits from a register into the target's second byte, which usually supplies a length. Compilers and assembler programmers use this for moves and compares whose length is only known at run time, such as a COBOL reference modification or a variable-length MVC. EXECUTE RELATIVE LONG (EXRL) does the same job with an address relative to itself.

The target can be almost any instruction, but not another EX or EXRL. If it is, the processor raises an execute exception, program interruption code 3, and z/OS ends the task with system completion code 0C3 and reason code 3.

Correctly generated code never points an EXECUTE at another EXECUTE. So an S0C3 means the target address is wrong or the bytes at the target have changed. For EX, the target address comes from a base register plus a displacement. If that register holds the wrong value, or the code at the target was overwritten, and the byte there happens to be X'44' (the EX operation code), you get this abend. In practice it is one of the least common program checks.

Common causes

• The base register an EX instruction uses was changed by a called routine that didn't restore registers, so the EX now points at the wrong place.
• A storage overlay wrote over non-reentrant code, and the bytes at an EX target are now an EX instruction.
• An assembler program builds or moves the target instruction at run time and gets it wrong.
• A program running with the wrong base register after a branch into the middle of another routine, so every EX in that routine computes a bad target.

How to find the problem

1. Find CEE3203S (Language Environment) or the IEA995I symptom dump in the job log. Note the PSW address, the ILC, and the load module name and offset.
2. The execute exception suppresses the instruction, so the PSW points just past the EX or EXRL. Subtract the ILC (4 for EX, 6 for EXRL) to find the failing EXECUTE, then match the offset to the compiler or assembler listing.
3. Decode the EX instruction to see which base and index registers form the target address, read them in the dump, and display the bytes at that address.
4. Compare those bytes with the listing. If the code in storage differs from the listing, something overwrote it. If the code matches but the register is wrong, trace where the register was last set.

How to fix it

• Make every called routine save and restore the caller's registers under the standard linkage conventions.
• Find and fix the storage overlay. In COBOL, check subscripts and reference modification lengths, and compile with SSRANGE in test.
• Link programs as reentrant where you can. z/OS normally loads reentrant modules into storage that a problem-state program can't change, which protects the code from overlays.
• If the failing module belongs to IBM or a vendor, search for a fix and report the problem with the dump.

What it looks like

IEA995I SYMPTOM DUMP OUTPUT
  SYSTEM COMPLETION CODE=0C3  REASON CODE=00000003
IEF450I PAYRUN01 STEP040 - ABEND=S0C3 U0000 REASON=00000003

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.