Diagnosing Unexpected Results in COBOL COMP‑3 Numeric Fields

Why COMP‑3 Can Behave Unexpectedly

COMP‑3 (packed‑decimal) stores each decimal digit in a nibble (half‑byte). The last nibble holds the sign: 0xC for positive, 0xD for negative. Because the data is not a plain ASCII string, a simple DISPLAY or a move from an alphanumeric field can corrupt the value or its sign. Additionally, arithmetic on a field that exceeds its precision silently truncates high‑order digits, and compiler options such as TRUNC(OPT) or BINARY influence how overflow is handled. These subtle differences often surface only at runtime, making the problem hard to diagnose.

Recognizable Conditions & Quick Diagnostic Table

Condition	Typical Symptoms	Likely Cause
Garbled numbers after a MOVE	Values look like random digits or include non‑numeric characters	Moving alphanumeric data into a COMP‑3 item without proper conversion
Sign inversion (negative reads as positive)	Negative input shows as positive output	Sign overpunch misinterpreted due to missing or incorrect REDEFINES
Silent truncation in arithmetic	Result has fewer digits and is incorrect	Operation exceeds defined precision and compiler truncates high‑order digits
Unexpected differences between debug print and runtime	Hex dump shows different bytes than expected	Compiler option TRUNC(OPT) or BINARY changes storage format

Ordered Checks – Step‑by‑Step

1. Verify the source data type – Ensure that the source of any MOVE to a COMP‑3 field is numeric or has been explicitly converted (e.g., MOVE FUNCTION NUMVAL-C (source) TO target). If the source is alphanumeric, the move will copy raw bytes, corrupting the packed representation.
2. Inspect the sign nibble – Use a hex viewer or DISPLAY HEX (if supported) to look at the last nibble of the COMP‑3 item. It should be 0xC or 0xD. Any other value indicates a sign error.
3. Check the PIC length – The target PIC must match the precision of all arithmetic that writes to it. If the PIC is too short, high‑order digits will be lost silently.
4. Confirm compiler options – Compile with TRUNC(STD) (or equivalent) and compare results. If the output changes, the issue is linked to truncation handling.
5. Re‑define with alphanumeric overlay – If you need to examine the raw bytes, use a REDEFINES clause that maps the COMP‑3 field to an alphanumeric array. Then inspect the sign nibble and data layout.

Concrete Example – Moving a Signed Number

Consider the following snippet that moves a signed integer into a COMP‑3 field:

01  WS-INT          PIC S9(4) COMP-3.
01  WS-ALPH         PIC X(4) VALUE "-123".

MOVE FUNCTION NUMVAL-C (WS-ALPH) TO WS-INT.

Without the NUMVAL-C function, the raw bytes "-123" would be copied, producing a garbled packed value. After the move, you can verify the result with a hex dump:

DISPLAY HEX (WS-INT).

The last nibble should be 0xD, confirming a negative sign, and the preceding nibbles should represent the digits 1, 2, and 3.

Fixes Tied to Findings

• Alphanumeric to COMP‑3 move – Use FUNCTION NUMVAL or NUMVAL-C to convert the string to a numeric value before moving.
• Sign overpunch misinterpretation – Always define a REDEFINES clause for debugging: 01 WS-INT-REDEF REDEFINES WS-INT PIC X(4). Then check the last byte.
• Precision mismatch – Expand the PIC of the target field or use COMPUTE with ROUNDED to avoid silent truncation.
• Compiler option differences – Standardize the truncation policy by compiling with TRUNC(STD) across all units, or document the difference if multiple options are required.

Escalation Criteria

If after applying the above fixes the problem persists, consider:

• Reviewing all MOVE statements that involve the problematic field across the codebase.
• Running a unit test that isolates the arithmetic operation and compares the result against a known good implementation.
• Consulting the compiler’s documentation for the specific TRUNC or BINARY options, as some vendors treat overflow differently.

Limitations & Practical Verification

COMP‑3 behavior can vary between compilers (IBM COBOL, Micro Focus, GnuCOBOL). Hex dumps must be interpreted in the context of the target platform’s endianess and sign‑overpunch encoding. Always validate the solution on the production environment’s compiler settings. A quick sanity check is to re‑compile the example program with TRUNC(STD) and compare the hex output; identical results confirm that the issue was not compiler‑specific.

Takeaway

Unexpected results in packed‑decimal fields are almost always due to a mismatch between data representation and the operations performed on them. By following a structured diagnostic checklist—checking source types, inspecting sign nibbles, verifying precision, and aligning compiler options—you can isolate the root cause quickly and apply the correct fix. Regularly use hex dumps and numeric conversions in your debugging workflow to keep COMP‑3 arithmetic reliable.