PIC clause causes unexpected storage length

Troubleshooting guide for PIC clause causes unexpected storage length. Data representation bugs are the most common COBOL production failures — they usually come from bad input data or PIC clauses that do not match the real data.

What it means

• COBOL trusts the PIC clause, not the data. If a PIC 9 field holds letters or a bad sign nibble, the program keeps running until an arithmetic verb blows up.
• Most of these bugs are silent: the program produces wrong output instead of abending, which makes them harder to catch than S0C7s.
• The fix pattern is almost always the same: validate input with IS NUMERIC / IS ALPHABETIC before arithmetic, and make PIC clauses match the real record layout.

Common causes

• Input file record contains spaces or letters in a numeric field (common after a layout change on the sending system).
• Packed-decimal (COMP-3) field has a corrupted sign nibble (last half-byte is not C, D, or F) — often from a bad MOVE of alphanumeric data into it.
• COMP-3 field defined with wrong length: PIC 9(5) COMP-3 needs 3 bytes; a 4-byte definition reads one byte too many.
• MOVE of a longer field into a shorter one silently truncates on the left for numeric items.
• REDEFINES overlays fields of different sizes, so changing one definition shifts every field after it.
• Numeric-edited field (PIC $$$,$$9.99) used in arithmetic without moving it to a pure numeric field first.
• PIC S9(4) COMP stores 2 bytes but the programmer assumed 4 — binary fields hold 2 bytes per 4 digits (COMP) or 9(9) needs 4 bytes.
• Date field validated nowhere: 20231345 (month 13) passes through until a date routine fails.

How to diagnose

• Display the suspect field in hex to see the real bytes: DISPLAY FUNCTION HEX-OF(WS-AMOUNT). A valid packed field ends in C, D, or F nibble.
• Add a one-time validation paragraph before the failing arithmetic: IF WS-FIELD IS NOT NUMERIC DISPLAY "BAD DATA: " WS-FIELD.
• Check the file layout (copybook) against the actual input record: compare LRECL and field offsets byte by byte.
• For REDEFINES problems, DISPLAY the lengths: a REDEFINES item must be the same size or smaller than the original.
• Ask the operations team for a hex dump of the failing input record (first 200 bytes are usually enough).

How to fix it

• Guard every arithmetic verb that touches file input: IF WS-AMOUNT IS NUMERIC COMPUTE ... ELSE reject the record.
• Correct the PIC clause to match reality, then recompile every program that uses the copybook (stale copybooks are a classic repeat cause).
• For packed fields, use FUNCTION NUMVAL on the alphanumeric source instead of moving raw bytes into COMP-3.
• After REDEFINES changes, re-verify total record length equals the FD record length — a mismatch shifts all fields.
• Add an edit routine at file read time that rejects bad dates, bad signs, and non-numeric numerics into an error file.

Example: COBOL defensive validation before arithmetic

IS NUMERIC catches bad data before it reaches COMPUTE; rejects go to an error file instead of abending the job.

Interview tip

• Q: Your batch job abends with S0C7 on PIC clause causes unexpected storage length. Walk me through your diagnosis.
• A: First I find the failing statement from the SYSUDUMP offset, then hex-display the input field to check the sign nibble and digit bytes. Most S0C7s come from non-numeric data moved into a numeric field, so I add an IS NUMERIC guard and check whether the copybook still matches the input layout.

Prevention checklist

• Validate every numeric field at file-read time with IS NUMERIC before any arithmetic.
• Keep one shared copybook per record layout and recompile all users when it changes.
• Add boundary test data: spaces, letters, and bad sign nibbles in numeric fields.
• Log rejected records with their key fields so bad data is traceable to the source system.