S0C2: Privileged operation exception

What it means

The processor runs every program in one of two states. Supervisor state is for the operating system and for authorized code that needs it. Problem state is for everything else, including ordinary batch and online programs. Some instructions are privileged, such as the ones that load a whole new PSW or set storage keys, and the processor refuses to run them in problem state. When a problem-state program tries one, the processor raises a privileged-operation exception, program interruption code 2. z/OS ends the task with system completion code 0C2 and reason code 2.

A few instructions are semiprivileged. Problem-state code may use them only when control bits in the PSW or the control registers allow it. Breaking that rule raises the same exception.

Compilers for COBOL, PL/I and C don't put privileged instructions into application code. So when one of these programs gets an S0C2, the bytes the processor tried to run were almost never meant as an instruction. The program branched to an address that holds data, or into code that had been overwritten, and the processor decoded those bytes as a privileged instruction.

Common causes

• A branch to a bad address. A return address in a save area was overwritten, a called program's entry address was wrong, or the program called through a procedure pointer or entry variable that was never set.
• The caller and the called program disagree about the parameter list, so the called program treats a data field as an address and branches through it.
• A table overrun or other storage overlay wrote over a save area, register save slot or non-reentrant code.
• An assembler routine issues a privileged instruction while in problem state, for example after switching back with MODESET MODE=PROB.
• Code written to run authorized was run from a library or environment where it doesn't get that authority.

How to find the problem

1. Find CEE3202S (Language Environment) or the IEA995I symptom dump in the job log. Note the PSW address, the instruction length code (ILC), and the load module name and offset if one is shown.
2. Check whether the failing address lies inside a program at all. If the dump can't place it in any load module, or it lands in a data area of your program, the program branched somewhere it shouldn't have.
3. Read registers 14 and 15 in the dump. Under the standard linkage they hold the return address and the entry address of the last call, which often show where the bad branch came from. The Language Environment traceback in CEEDUMP lists the calling sequence.
4. Display the bytes just before the PSW address. If they look like character data, a table or a record, you're looking at a wild branch, not a real instruction.

How to fix it

• Fix the source of the bad address. Set every procedure pointer before calling through it, and make the caller's CALL USING list match the called program's PROCEDURE DIVISION USING list.
• Recompile and relink every program that shares a changed copybook or parameter layout, so no caller passes an old layout.
• Add range checks to subscripts, or compile with SSRANGE in test, so a table overrun can't overwrite save areas.
• In assembler, issue privileged instructions only in supervisor state, and keep register 14 and the save area chain intact across calls.
• If the failing code belongs to IBM or a vendor product, search for a fix (APAR or PTF) and send the dump with your problem report.

What it looks like

IEA995I SYMPTOM DUMP OUTPUT
  SYSTEM COMPLETION CODE=0C2  REASON CODE=00000002
IEF450I ORDENTRY STEP010 - ABEND=S0C2 U0000 REASON=00000002

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.