S0CA: Decimal overflow exception
An S0CA abend means a packed decimal instruction produced a result with more significant digits than the receiving field can hold, and the program had told the processor to report decimal overflow. The high-order digits are lost, and the step ends instead of carrying on with the wrong value.
Other names for this code
Also written as 0CA, SOCA, abend 0CA, system abend 0CA, S0CA-A, decimal overflow, decimal overflow exception.
What it means
Packed decimal instructions such as ADD DECIMAL (AP), SUBTRACT DECIMAL (SP), ZERO AND ADD (ZAP) and SHIFT AND ROUND DECIMAL (SRP) store their result in the first operand. When the result has more significant digits than that field can hold, the processor stores what fits, drops the high-order digits, and sets condition code 3. It then checks the decimal overflow mask bit in the program mask of the PSW. If the bit is on, it raises a decimal overflow exception, program interruption code 10 (hex A), and z/OS ends the task with system completion code 0CA and reason code A.
Decimal overflow is one of the four program checks a program can switch off. With the mask bit off, the truncated value is kept and the program carries on, which is often worse than an abend because nobody notices.
Compiled COBOL deals with oversize results in its own code, through its truncation rules and ON SIZE ERROR, so COBOL programs rarely end with S0CA. It shows up mainly in assembler programs, and in other code that runs with the mask on.
Common causes
- A running total or counter kept in a packed field that was sized for normal volumes, and the volume grew.
- An AP or ZAP into a receiving field shorter than the source, so the value doesn't fit.
- An SRP shift to the left that moves significant digits off the end of the field.
- A packed field that was never initialized holds a large leftover value that is still valid packed data, so the arithmetic runs and overflows instead of failing with S0C7.
How to find the problem
- Find CEE3210S (Language Environment) or the IEA995I symptom dump in the job log. Note the program name, the PSW address and the offset.
- Overflow is reported after the instruction completes, so the PSW points to the next instruction. Subtract the ILC and match the offset to the listing to find the AP, SP, ZAP or SRP.
- Compare the length of the receiving field with the size of the value being stored. The field in the dump holds the truncated result.
- Check where the large value came from, such as an input amount, a total, or an uninitialized field.
How to fix it
- Make the receiving field long enough for the largest value it can really get.
- Check input amounts and totals against a sensible limit before adding them.
- Initialize packed fields before use, for example with ZAP from a packed zero.
- Switch the decimal overflow mask off only where truncation is what the program wants, and then test condition code 3 yourself.
What it looks like
IEA995I SYMPTOM DUMP OUTPUT SYSTEM COMPLETION CODE=0CA REASON CODE=0000000A IEF450I PAYRUN01 STEP050 - ABEND=S0CA U0000 REASON=0000000A
IBM documentation
IBM z/OS: 0Cx program interruptions. Use the documentation for your installed release.
Related codes
Questions
What is the difference between S0CA and S0C7?
S0C7 means a field didn't hold valid packed data. S0CA means the data was valid but the result was too large for the field it went into.
What is the difference between S0CA and S0CB?
S0CA is an add, subtract or shift result that doesn't fit. S0CB is a packed decimal divide that failed, usually because the divisor was zero.
Why don't COBOL programs usually get S0CA?
Compiled COBOL handles results that are too large in its own code, through truncation or ON SIZE ERROR. It doesn't rely on the hardware interrupt.