S0CB — decimal divide exception

A packed-decimal divide failed — almost always because the divisor was zero; rarely the quotient was too large for the instruction's work area.

What happened

The step abends with system completion code 0CB at a DIVIDE or a COMPUTE containing division.

Typical JES message (illustrative)

IEA995I SYMPTOM DUMP OUTPUT
SYSTEM COMPLETION CODE=0CB  REASON CODE=0000000B
PSW AT TIME OF ERROR  078D1000   9A4D18A2  ILC 6  INTC 0B
ACTIVE LOAD MODULE  ADDRESS=1A4D1000  OFFSET=000008A2
NAME=RATECALC
CEE3211S The system detected a decimal-divide exception (System Completion Code=0CB).
IEF450I RATEJOB1 STEP020 - ABEND=S0CB U0000 REASON=0000000B

What it means

A decimal divide instruction could not produce a result. Either the divisor was zero, or the quotient would not fit in the space the instruction had for it. The data was valid numbers — otherwise you would get S0C7 first — but the division itself was impossible.

COBOL generates decimal instructions for packed decimal and often zoned fields. Binary division by zero gives S0C9 instead. Exactly which instructions the compiler uses depends on the compiler version, options and field types.

Typical causes

The divisor was zero — a count, rate or quantity field that was empty for this record.
A divisor field correctly initialised to zero but never set because of a missing READ or branch.
Rarely, a quotient too large for the intermediate work area the compiler used; a quotient too large for the COBOL receiving field is truncated (or raises ON SIZE ERROR) rather than causing S0CB.
Wrong field layout, so the program read a different field as the divisor.

Symptoms

It is data-dependent and repeats on the same record. Zero is a valid packed number (X'0C' or X'0F'), so the field passes an IS NUMERIC test — unlike spaces, which give S0C7. It differs from S0CA, decimal overflow, which COBOL programs do not normally abend on; the result is truncated instead.

Where to look

JESMSGLG: completion code, program and offset.
CEEDUMP: traceback and, with TEST, statement numbers and field values.
The compile listing to map the offset to the DIVIDE or COMPUTE.
The input record, browsed with HEX ON.

How to diagnose

Map the offset to the statement.
List the divisor and the result field for that statement.
Find the record being processed and look at the divisor's value.
If the divisor is non-zero, compare the expected quotient with the size of the result field.
Trace where the divisor was set, and why it was zero for this record.

How to fix

Guard the divide. Test the divisor for zero before dividing and handle the case the business way — skip, default, or report. Add ON SIZE ERROR to DIVIDE or COMPUTE so a bad result is handled instead of abending. Widen the result field if the quotient can legitimately be large, but note that this prevents truncation and size errors; it does not cure an S0CB caused by a zero divisor. Then rerun after checking the step's outputs.