S0C1 — operation exception

The processor was asked to run bytes that are not a valid instruction — usually because control went to the wrong place.

What happened

The step abends with system completion code 0C1. The failing address is often outside your program, or the offset makes no sense in the listing.

Typical JES message (illustrative)

IEA995I SYMPTOM DUMP OUTPUT
SYSTEM COMPLETION CODE=0C1  REASON CODE=00000001
PSW AT TIME OF ERROR  078D1000   00000002  ILC 2  INTC 01
NO ACTIVE MODULE FOUND
CEE3201S The system detected an operation exception (System Completion Code=0C1).
IEF450I ORDJOB01 STEP040 - ABEND=S0C1 U0000 REASON=00000001

What it means

The CPU fetched something to execute and the operation code was not a valid instruction on this machine. Programs compiled by a supported compiler do not generate invalid instructions, so the usual meaning is that control was passed to an address that does not hold code — data, zeroed storage, or a module that is not what the caller expected.

The question is rarely "what is wrong with this instruction?" It is "how did the program get here?"

Typical causes

A branch to an invalid address — for example a CALL through an entry point that resolved to zero, or a return to a corrupted return address.
A missing or wrong-level load module, so the program called is not the one the caller was built for.
A called program that was not link-edited correctly, such as one with unresolved external references that the binder accepted with a warning.
Storage overlaid by the program, for example a table overflow that wrote over saved addresses.
Less often, code built for a newer machine level running on an older processor; this is a build or site configuration issue.

Symptoms

The PSW address is often very low, or points into data or outside any module, and the symptom dump may report no active module. That separates it from S0C4, where the instruction is valid but its operand address is bad. If the module itself was marked not executable, you get S706 instead, and a module that cannot be found gives S806.

Where to look

JESMSGLG: the symptom dump, PSW and active module, if any.
CEEDUMP: the traceback shows the last programs that were active, which is often more useful than the failing address.
The breaking-event address, if shown in the dump, which records the last branch taken before the failure.
Binder output for every module in the call chain.
JESJCL: the STEPLIB concatenation, to see which copy of each module was loaded.

How to diagnose

Note the PSW address and whether it falls inside a known module.
Use the CEEDUMP traceback and breaking-event address to find the last program in control.
Look at the CALL or return made at that point.
Check the binder output for warnings about unresolved references.
Confirm the version of each called module in the libraries actually searched.
If nothing changed in the modules, suspect a storage overlay and test with SSRANGE.

How to fix

Fix the cause you found: relink the module cleanly, promote the correct level of every program in the chain, correct the CALL interface, or fix the code that overwrote storage. Rerun only once you know whether earlier steps or partial updates need backing out.