Group Items and Record Layouts

Modern languages use structs or classes to group related variables together in memory, forming complex objects that the runtime tracks. COBOL was designed before these concepts existed, built specifically to process fixed-width records from punched cards and magnetic tape. Instead of defining a type and then instantiating it, COBOL programs define a hierarchical structure directly in memory using group items.

A group item is a variable that contains other variables, which are called elementary items. You create a hierarchy by using different level numbers. The lower the level number, the higher it is in the hierarchy. The 01 level is the highest level, typically representing an entire record layout on a file or a screen. This directly mirrors how data is stored, which is why COBOL is still uniquely suited for processing vast amounts of structured text data in banking and finance systems.

IDENTIFICATION DIVISION.
PROGRAM-ID. GROUP-ITEMS.
DATA DIVISION.
WORKING-STORAGE SECTION.
01  CUSTOMER-RECORD.
    05  CUSTOMER-ID      PIC 9(5) VALUE 12345.
    05  CUSTOMER-NAME.
        10  FIRST-NAME   PIC X(10) VALUE 'JOHN      '.
        10  LAST-NAME    PIC X(10) VALUE 'DOE       '.
    05  CUSTOMER-AGE     PIC 9(3) VALUE 035.

PROCEDURE DIVISION.
    DISPLAY "Customer Record: " CUSTOMER-RECORD
    DISPLAY "First Name:      " FIRST-NAME
    STOP RUN.

Customer Record: 12345JOHN      DOE       035
First Name:      JOHN      

The Illusion of Objects

A reasonable programmer coming from Java, Python, or C++ might look at CUSTOMER-RECORD and think it acts like an object or a pointer reference. It does not. It is not a distinct entity with its own metadata or memory allocation.

In COBOL, a group item is nothing more than a convenient name for a contiguous, uninterrupted block of bytes. When you refer to CUSTOMER-RECORD, you are referring precisely to the 28-byte block of memory that starts at CUSTOMER-ID and ends at CUSTOMER-AGE (5 + 10 + 10 + 3 = 28 bytes).

This is why group items never have a PIC clause. They do not hold their own data; their size and content are entirely defined by the mathematical sum of their elementary items. If you add a PIC clause to a group item, the compiler will instantly reject your code.

The Boundary: Group Items are Alphanumeric

Because a group item is fundamentally just a raw span of bytes, the compiler always treats group items as alphanumeric strings (PIC X), regardless of what data types are defined inside them.

You can MOVE a group item as a single chunk of text, which is an incredibly efficient way to copy entire records from one place in memory to another without iterating over fields. However, this alphanumeric nature leads to a common beginner mistake: you cannot perform math on a group item.

Can you predict what will happen if we move a group item that starts with a number into a group item that starts with letters?

IDENTIFICATION DIVISION.
PROGRAM-ID. GROUP-MOVE.
DATA DIVISION.
WORKING-STORAGE SECTION.
01  SOURCE-REC.
    05  ID-NUM    PIC 9(2) VALUE 12.
    05  MY-CODE   PIC X(3) VALUE 'ABC'.
01  DEST-REC.
    05  FLDA      PIC X(3) VALUE 'XYZ'.
    05  FLDB      PIC 9(2) VALUE 99.
PROCEDURE DIVISION.
    MOVE SOURCE-REC TO DEST-REC.
    DISPLAY DEST-REC.
    STOP RUN.

12ABC

If COBOL were trying to align sub-fields by their data type, it might try to match the PIC 9 numbers together or throw an error about type mismatch. It doesn’t do any of that. The entire SOURCE-REC is treated as a single 5-character string "12ABC", which is then blindly copied over the 5 bytes of DEST-REC.

This strictly enforced boundary ensures that COBOL programs can rapidly copy entire fixed-width record layouts from disk to memory and back again, without the overhead of deeply inspecting every single elementary item during a MOVE.