| name | comp3-packed-decimal |
| description | Reference for COBOL COMP-3 (packed decimal / BCD) numeric storage -- layout on disk, declaring it in the FD, and pitfalls when carrying the decoded value through working storage and into later arithmetic. Useful when an input record holds a balance, rate, or carry-forward as packed decimal rather than a printable digit string. |
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:
- The COMP-3 column is decoded correctly in the FD-side record (the
master lookup returns the right number).
- 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.
- 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
