Explain COBOL Data Types: PIC Clauses, COMP and COMP-3 in IBM Mainframes

2 / 60

COBOLbeginner

COBOL Data Types: PIC Clauses, COMP and COMP-3

Know how COBOL declares data storage and why COMP-3 packed decimal is the default choice for numeric fields on the mainframe.

COBOL has no int or float. A field's shape comes from its PICTURE clause and its storage format from its USAGE clause.

DISPLAY is like writing each digit of a number on its own index card — clear to read but bulky to carry; COMP-3 is like folding two digits onto every card, half the stack, still perfectly legible if you know the fold.

Key Concepts

The same nine digits can occupy nine bytes, five, or four, depending entirely on usage.

    PIC 9(9)            DISPLAY   9 bytes -- one byte per digit
    PIC 9(9) COMP-3     packed    5 bytes -- two digits per byte, plus sign
    PIC 9(9) COMP       binary    4 bytes -- a true binary integer

DISPLAY is the default, and it is one byte per digit. The value 12345 is stored as the characters for 1, 2, 3, 4 and 5. Readable in a hex dump and wasteful.

COMP-3 packs two digits into each byte, with the last nibble holding the sign:

    value 12345, PIC 9(5) COMP-3
    bytes:  12 34 5C        <- C means positive, D negative
    3 bytes instead of 5

The formula, which interviewers ask you to apply. Digits plus one for the sign, divided by two, rounded up:

    PIC 9(5)  COMP-3  ->  (5+1)/2 = 3 bytes
    PIC 9(7)  COMP-3  ->  (7+1)/2 = 4 bytes
    PIC 9(9)  COMP-3  ->  (9+1)/2 = 5 bytes

Why COMP-3 is the industry default for money. It halves storage against DISPLAY, and — unlike binary floating point — it is exact in decimal. A financial calculation cannot afford 0.1 not being 0.1.

Multiply that saving across a file of a hundred million records and it is the difference between a reasonable dataset and an unreasonable one.

COMP is a true binary integer and is fastest for arithmetic. Use it for counters and subscripts, where the value is a count rather than an amount.

The REDEFINES trap, which is the other standard question. Looking at a COMP-3 field through a DISPLAY redefinition shows nonsense, because you are reading packed nibbles as characters.

    stored:    12 34 5C
    as DISPLAY: unprintable bytes

Nothing is corrupt. You asked for the wrong interpretation of the same bytes, which is exactly what REDEFINES does.

The signed picture. PIC S9(5) holds a sign; PIC 9(5) does not, and storing a negative value in it loses the sign silently. On a monetary field that is a real defect and it produces no error.

PIC S9(5)PIC 9(5)

What the interviewer is probing.1. "What is COMP-3 and why is it everywhere?" Probing: the core. Stalls: "A number." *Moves up:* packed decimal — two digits per byte plus a sign nibble, exact for money and far more compact than display format.

2. "When would you use COMP instead?" Probing: the distinction. Stalls: "They are the same." Moves up: binary, for counters and subscripts where arithmetic speed matters and the value is not a currency amount.

3. "Why is a signed field often declared with an odd number of digits?" Probing: the detail. Stalls: "Convention." Moves up: COMP-3 stores digits in half-bytes plus a sign nibble, so an odd digit count fills whole bytes with no wasted half.

4. "What goes wrong mixing display and packed fields?" Probing: the practical failure. Stalls: "Nothing." Moves up: a MOVE between mismatched pictures can truncate or produce a data exception, which is the classic S0C7 abend.