COBOLintermediate
Subroutines: CALL, Static vs Dynamic
Distinguish static and dynamic CALL in COBOL and understand the tradeoffs each brings to modularity and deployment.
COBOL programs invoke other programs as subroutines via the CALL statement, and one of the most consequential decisions in a mainframe shop's architecture is whether those calls are static or dynamic — a distinction that affects link-editing, module size, and how easily a called program can be updated independently.
A static call is like printing a phone number directly on a business card — reliable and instant, but every card needs reprinting if the number changes. A dynamic call is like looking the number up in a directory each time you dial — one directory update fixes it for everyone, at the cost of a lookup each call.
Key Concepts
1
A static CALL uses a literal program name known at compile time (CALL 'SUBPGM'), and the linkage editor or binder physically embeds the called module's object code into the calling program's load module. This makes execution fast (no runtime lookup) but means every caller must be re-link-edited whenever the called subroutine changes — a real operational cost in large systems with many callers.
CALL 'SUBPGM'
2
A dynamic CALL uses a variable holding the program name (CALL WS-PGM-NAME), resolved at runtime by loading the target module from a library search (STEPLIB/JOBLIB or LPA). This decouples caller and callee — you can redeploy the subroutine independently — at the cost of a small runtime lookup overhead and the operational risk of the wrong version being picked up if library concatenation order isn't controlled carefully.
CALL WS-PGM-NAME
3
Interviewers often frame this as: 'Your team ships a bug fix to a commonly-called subroutine — what's the blast radius, and how does it differ between static and dynamic CALL?' The expected answer is that static callers must all be recompiled/relinked to pick up the fix, while dynamic callers pick it up automatically the next time the module is loaded, assuming the corrected load module lands in the right library ahead of the old one in the search order.