All topics
7 / 60
COBOLbeginner

Copybooks and Shared Data Structures

Explain how copybooks provide shared, reusable record layouts across COBOL programs and why they're central to mainframe maintainability.

A copybook is a source member containing a record layout, inserted into a program at compile time:

A copybook is the master blueprint kept in a shared architecture office — every contractor building a similar house copies the same wiring diagram instead of redrawing it from memory, so a code violation found in one house gets fixed everywhere the blueprint is used.

Key Concepts

1
    01  CUSTOMER-RECORD.
        COPY CUSTREC.
2
The compiler pastes the copybook's text in. It is textual inclusion, resolved before compilation, with no runtime component at all.
3
Why every shop depends on them. Twenty programs read the customer file. Each needs the same record layout — the same fields, the same lengths, at the same offsets.
4
Retyping that in twenty programs guarantees they drift. One program gets the field length wrong, reads at the wrong offset, and produces plausible garbage. Copybooks make the layout one definition that everyone references.
5
REPLACING lets one copybook serve several uses.
    COPY CUSTREC REPLACING ==:PFX:== BY ==OLD==.
REPLACING
6
Placeholders in the copybook become prefixes in the program, so the same layout can be included twice — OLD-CUSTOMER-ID and NEW-CUSTOMER-ID — for comparing a before and after image.
OLD-CUSTOMER-IDNEW-CUSTOMER-ID
7
They can hold procedural code too, and usually should not. Logic hidden behind a COPY is logic that does not appear when you read the program, which makes control flow much harder to follow.
COPY
8
The question that matters: what happens when a field's length changes?
    1. update the copybook
    2. recompile EVERY program that copies it
    3. convert the existing data files to the new layout
    4. coordinate all of that into one release
9
Step 2 is the one that gets missed, and the consequence is precise. A program compiled against the old layout reads at the old offsets. The file now has the new layout. Every field after the changed one is read from the wrong bytes — and the program does not fail, because bytes are bytes. It produces wrong numbers.
10
Step 3 is missed almost as often. Existing files were written under the old layout and do not change because a copybook did.
11
Which is why shops maintain a cross-reference of which programs copy which copybooks, and why the build process recompiling all dependents is an operational discipline rather than a detail. A copybook change with an incomplete recompile is one of the classic ways to corrupt a production file quietly.
12
What the interviewer is probing.1. "What problem do copybooks solve?" Probing: the purpose. Stalls: "Reuse." Moves up: one definition of a record layout shared by every program that reads it, so a field change is made once.
13
2. "What must happen after changing a copybook?" Probing: the operational consequence. Stalls: "Nothing." Moves up: every program using it must be recompiled — a stale load module reading the new layout is a production incident waiting to happen.
14
3. "What is the REPLACING option for?" Probing: the technique. Stalls: "Nothing." *Moves up:* substituting a prefix so the same layout can be included twice under different names, which is how you compare old and new records.
15
4. "Why keep copybooks under the same source control as programs?" Probing: the discipline. Stalls: "Convenience." Moves up: because the impact analysis for a change depends on knowing every consumer — and that list is only reliable if it is versioned together.
Use cases:copybookscode-reusemaintainabilitydata-structures