Subprograms and CALL Statements

Analogy categoryAnalogies

Introduction to Subprograms

A COBOL subprogram is a separately compiled unit of PROCEDURE DIVISION logic that a calling program invokes with the CALL statement instead of duplicating code inline. The calling program issues CALL 'SUBPROG' USING param-1 param-2, control transfers to the subprogram's PROCEDURE DIVISION, and the subprogram runs until it hits GOBACK or EXIT PROGRAM, at which point control returns to the statement immediately after the CALL. This mirrors how mainframe shops decompose large batch systems, such as a payroll run, into validation, calculation, and reporting subprograms that can each be tested, compiled, and maintained independently.

🏏

Cricket analogy: A CALL statement is like a captain bringing on a specialist bowler such as Rashid Khan for a specific over rather than the same bowler doing every delivery; the main strategy hands off a defined task and resumes once the over is complete.

Static CALL vs Dynamic CALL

A static CALL uses a literal program name, such as CALL 'CALCTAX', and the linkage editor resolves that reference at link-edit time, embedding the subprogram's address directly into the load module; this is fast at runtime but means the main program must be re-link-edited whenever the subprogram changes. A dynamic CALL uses a data item instead of a literal, such as CALL WS-PROGRAM-NAME USING ..., and the operating system resolves and loads the subprogram at execution time, which lets shops swap subprogram versions without relinking the caller. Dynamic calls stay resident until an explicit CANCEL statement releases the subprogram's storage and resets its internal state, including any WORKING-STORAGE values retained between calls.

🏏

Cricket analogy: A static CALL is like a franchise naming its playing XI on the team sheet before the toss, fixed for the match, while a dynamic CALL is like a T20 auction where the squad can be reshuffled match to match without rewriting the tournament rules.

Passing Parameters: BY REFERENCE, BY CONTENT, and BY VALUE

The default passing mechanism, BY REFERENCE, passes the address of a WORKING-STORAGE item, so any change the subprogram makes to the corresponding LINKAGE SECTION item is visible back in the calling program the moment control returns; this is how a subprogram commonly returns a computed result or a status flag. BY CONTENT passes a copy of the data at the moment of the call, so the subprogram can freely modify its local copy without any risk of corrupting the caller's original value, which is useful for read-only inputs like a company-code filter. BY VALUE, available in COBOL 2002 and later and commonly used when calling non-COBOL routines through a C-style interface, passes a literal or numeric value directly rather than an address, and the receiving LINKAGE SECTION item's PICTURE clause must be compatible in type and size with what the caller sends.

🏏

Cricket analogy: BY REFERENCE is like handing the actual scorebook to the scorer, so any correction they make is the official record, while BY CONTENT is like giving a commentator a photocopy of the scorecard they can annotate freely without altering the official book.

cobol

       IDENTIFICATION DIVISION.
       PROGRAM-ID. MAINPGM.
       DATA DIVISION.
       WORKING-STORAGE SECTION.
       01  WS-EMP-SALARY       PIC 9(7)V99 VALUE 45000.00.
       01  WS-TAX-RATE         PIC 9(1)V999 VALUE 0.220.
       01  WS-TAX-AMOUNT       PIC 9(7)V99 VALUE 0.
       01  WS-PGM-NAME         PIC X(8) VALUE 'CALCTAX '.

       PROCEDURE DIVISION.
           CALL WS-PGM-NAME USING BY REFERENCE WS-EMP-SALARY
                                   BY CONTENT   WS-TAX-RATE
                                   BY REFERENCE WS-TAX-AMOUNT
           END-CALL
           DISPLAY 'TAX COMPUTED: ' WS-TAX-AMOUNT
           CANCEL WS-PGM-NAME
           STOP RUN.

       IDENTIFICATION DIVISION.
       PROGRAM-ID. CALCTAX.
       DATA DIVISION.
       LINKAGE SECTION.
       01  LK-SALARY           PIC 9(7)V99.
       01  LK-RATE             PIC 9(1)V999.
       01  LK-TAX              PIC 9(7)V99.

       PROCEDURE DIVISION USING LK-SALARY LK-RATE LK-TAX.
           COMPUTE LK-TAX = LK-SALARY * LK-RATE
           GOBACK.

The number, order, and data type of items in the calling program's CALL ... USING clause must exactly match the subprogram's PROCEDURE DIVISION USING clause. A mismatch, such as passing a PIC 9(7)V99 item where the subprogram expects PIC 9(9), will not raise a compile error across separately compiled programs and can corrupt data or abend at runtime, so many shops enforce matching parameter lists through a shared copybook.

Nested Programs and External Subprograms

COBOL supports nested subprograms, defined between an inner PROGRAM-ID and END PROGRAM inside an enclosing program's source, which can share the outer program's data items if those items are declared with the GLOBAL clause, avoiding the need to pass every value through USING. External subprograms, by contrast, are compiled as entirely separate load modules with their own independent WORKING-STORAGE, and the only way data crosses the boundary is through the LINKAGE SECTION parameters on the CALL and PROCEDURE DIVISION USING statements or through shared files and databases. Most enterprise COBOL shops favor external subprograms for reusable business logic, such as a date-validation routine called from dozens of programs, because they compile independently and can be unit tested and version-controlled in isolation from any single calling program.

🏏

Cricket analogy: A nested subprogram is like an all-rounder who bats and bowls within the same team, sharing the dressing room and team strategy directly, while an external subprogram is like a specialist commentator brought in from a broadcaster who only interacts through the official scorecard feed.

Failing to CANCEL a dynamically called subprogram between logically separate transactions can leave stale WORKING-STORAGE values from a previous call in place, because COBOL subprograms retain their state across calls until canceled or the run unit ends. This has caused subtle production bugs where a subprogram's accumulator or flag from customer A's transaction silently carried over into customer B's processing.

CALL invokes a subprogram; GOBACK or EXIT PROGRAM returns control to the statement after the CALL.
Static CALL uses a literal name resolved at link-edit time; dynamic CALL uses a data item resolved at runtime.
BY REFERENCE (the default) shares the caller's actual storage; BY CONTENT passes a protected copy; BY VALUE passes a literal, common when interfacing with non-COBOL code.
The CALL ... USING parameter list must match the subprogram's PROCEDURE DIVISION USING list in count, order, and type.
Nested subprograms can share GLOBAL data with the enclosing program; external subprograms only exchange data through LINKAGE SECTION parameters.
Dynamically called subprograms retain WORKING-STORAGE values between calls until an explicit CANCEL releases them.
External subprograms are preferred for reusable business logic because they compile, version, and test independently of any single caller.