COBOL Dynamic CALL Risk
Why runtime program resolution collapses call-graph guarantees — and why authority must refuse.
What a Dynamic CALL Is
A dynamic CALL in COBOL uses a variable to specify the program name rather than a static literal.
MOVE 'CALCRATE' TO WS-PROGRAM-NAME.
CALL WS-PROGRAM-NAME USING WS-DATA.
Unlike a static CALL, the target program is not fixed at compile time. It is resolved at runtime.
The program name may originate from:
- Configuration files
- Database tables
- External input
- Prior program logic
Why Dynamic CALL Breaks Call-Graph Analysis
Static analysis relies on a complete and enumerable call graph.
With dynamic CALL, the call graph is not enumerable from source artifacts.
At analysis time, the variable may take one of many values — or values that do not exist in the analyzed artifact set at all.
The result is a call edge that cannot be resolved deterministically.
Why “We Know the Possible Targets” Is Not Proof
Dynamic CALL is often defended with statements such as:
- “It only ever calls one of three programs.”
- “The values are controlled.”
- “We validate inputs elsewhere.”
These are operational assurances, not source-derived guarantees.
Unless the set of possible targets is provably constrained within the analyzed artifacts, authority cannot assume completeness.
Dynamic CALL and Modernization Failure Modes
Automated migration tools frequently mis-handle dynamic CALL because they must choose between:
- Assuming a subset of possible targets
- Inlining incorrect logic
- Dropping unresolved dependencies
These failures often surface only after deployment, when a previously unobserved runtime value is encountered.
Why Authority Must Refuse
Issuing a GO decision in the presence of unresolved dynamic CALL would require assuming a closed world of runtime targets.
That assumption cannot be proven from source artifacts alone.
Under strict governance contexts — Production · Regulated · High — authority must therefore refuse.
Related boundary types include ALTER control-flow mutation and CICS error-handling omissions.
What Governance Teams Can Do
When dynamic CALL is detected, institutions typically:
- Refactor to static CALL where feasible
- Isolate dynamic dispatch into controlled interfaces
- Accept refusal and document the boundary explicitly
How This Research Is Used in Authority Records
Authority records cite this page as the public definition of why unresolved dynamic CALL terminates provability.
This ensures refusals are consistent, auditable, and independent of operator judgment.
Explicit Non-Claims
- No runtime simulation
- No exploitability claims
- No compliance certification
- No probability or confidence scoring
- No prediction of behavior for any specific codebase
This article describes general provability boundaries associated with COBOL dynamic CALL usage. It does not analyze any specific institution’s code. No governance decision is issued by this page.