Subprograms, CALL, USING, LINKAGE SECTION, and Modular Design
Break large COBOL systems into reusable modules and understand how programs exchange data safely.
Inside this chapter
- Why Modular COBOL Matters
- CALL Statement
- USING and LINKAGE
- Reusability and Separation of Concerns
- Real Example
Series navigation
Study the chapters in order for the clearest path from COBOL basics to enterprise batch processing, operational context, and modernization strategy. Use the navigation at the bottom to move smoothly through the full tutorial series.
Why Modular COBOL Matters
Large enterprise programs become difficult to manage if every rule is written in one place. Modular design through called programs and structured interfaces helps keep systems maintainable.
CALL Statement
CALL "CALCTAX" USING TAX-INP, TAX-OUT.Calling a subprogram lets one COBOL module delegate specialized work to another, such as tax computation, validation, enrichment, or formatting logic.
USING and LINKAGE
Data passed between programs is often defined through the LINKAGE SECTION and parameter contracts. In long-lived systems, these interfaces need to remain stable and well understood.
Reusability and Separation of Concerns
A common pattern is to keep file reading in one module, calculations in another, and external formatting or reporting in yet another. This makes testing, maintenance, and enhancement more manageable.
Real Example
An insurance platform may call one subprogram to compute premium adjustments, another to validate policy eligibility, and another to prepare regulatory output records. Modular COBOL helps contain complexity in such systems.