COMP-3 / packed decimal storage

USAGE COMP-3 (a.k.a. PACKED-DECIMAL) stores a signed numeric field as binary-coded-decimal nibbles: each byte holds two decimal digits, except the last byte whose low nibble is the sign:

PIC S9(11)V99 USAGE COMP-3
+--+--+--+--+--+--+--+
|D1|D2|D3|D4|D5|D6|D7|   7 bytes total for 13 digits
+--+--+--+--+--+--+--+
              ^^-- sign nibble in the LOW half of the last byte

Bytes-on-disk = ceil((digit_count + 1) / 2). For PIC S9(11)V99 that is ceil(14 / 2) = 7 bytes. The high nibble of the first byte holds the first decimal digit; the implied decimal point is not stored.

Sign nibbles:

Nibble	Meaning
C	positive (some shops emit F for unsigned, but C is standard for SIGNED)
D	negative
F	unsigned / non-S PIC

Declaring COMP-3 in an FD

The record layout must match the byte budget. If the data in the file is packed but you declare the field as PIC X(n) or as an unpacked decimal, the COBOL runtime will not decode it and the value will look like binary garbage when displayed.

FD  MAST-FILE
    RECORD CONTAINS 80 CHARACTERS.
01  MAST-REC.
    05  M-ACCT     PIC X(6).
    05  M-TYPE     PIC X.
    05  M-STATUS   PIC X.
    05  M-CCY      PIC X(3).
    05  M-CARRY    PIC S9(11)V99 USAGE COMP-3.   *> 7 bytes
    05  FILLER     PIC X(62).                    *> remainder of 80

Use a runtime check: cobc -x -free -o prog PROG.cbl && ./prog and DISPLAY one record's COMP-3 field before relying on it. Common mistakes:

• Forgetting the USAGE COMP-3 clause -> the field is read as 7 zoned ASCII characters; values look like control characters.
• Wrong digit count -> the byte budget changes and subsequent fields slide.
• Moving COMP-3 directly into a PIC X(7) workspace -> the bytes copy but no arithmetic translation happens; the value is unusable.

Carrying the value through working storage

A common defect when there is an opening balance / carry-forward column:

1. The COMP-3 column is decoded correctly in the FD-side record (the master lookup returns the right number).
2. But when the per-account accumulator row is created later in the program, the carry-forward seed is initialised to a constant (often zero) instead of being copied from the lookup result.
3. Every account is then summed up correctly from the detail tape but the opening balance is silently dropped at output time.

The cure is structural, not a single magic line: when you allocate a new accumulator row, seed every column that has a meaningful starting value — including the decoded carry-forward — rather than leaving it at its INITIALIZE/VALUE ZERO default. Pseudocode with placeholder names (adapt to your own record and table identifiers):

       *> placeholders: <new-row> is the freshly allocated accumulator,
       *> <decoded-carry> is the COMP-3 value from the master lookup.
       IF row-not-yet-present
           allocate <new-row>
           MOVE <account-key>   TO key-of   (<new-row>)
           MOVE <currency>      TO ccy-of   (<new-row>)
           MOVE <decoded-carry> TO carry-of (<new-row>)   *> seed, don't zero
           MOVE <period-delta>  TO delta-of (<new-row>)
       END-IF

The point is to recognise which fields need a non-zero seed at row creation; the exact MOVE targets depend on how your program names its balance table.

Verification tip

od -An -tx1 ACCT.MASTER | head and confirm bytes 11-17 of one record match the expected packed nibbles for that account's known opening balance. A few hand-decoded rows are usually enough to confirm both the FD declaration and the carry-through logic.

References

• IBM Enterprise COBOL Language Reference -- "USAGE PACKED-DECIMAL / COMP-3"
• GnuCOBOL documentation on USAGE clauses and arithmetic on packed fields