COBOL ALTER Statement Risk

What the ALTER Statement Does

The ALTER statement is one of the most powerful — and most dangerous — constructs in the COBOL language.

It modifies the destination of a GO TO statement at runtime. This means the execution target of a paragraph is not fixed at compile time, but can be redirected dynamically during program execution.

ALTER PARA-A TO PROCEED TO PARA-C.

...

PARA-A.
    GO TO PARA-B.
    

After the ALTER executes, GO TO PARA-B no longer goes to PARA-B. It goes to PARA-C.

Which path is taken depends entirely on runtime execution history.

Why ALTER Breaks Static Analysis

Static analysis depends on being able to enumerate all possible execution paths from source artifacts.

The moment ALTER is introduced, the control-flow graph becomes state-dependent.

The next target of a GO TO depends on:

• Whether an ALTER has executed
• Which ALTER executed last
• The order in which prior paragraphs were invoked

None of this can be proven from source alone.

The control-flow graph is no longer static. It is runtime-mutable.

Why “But It Works in Production” Is Irrelevant

ALTER is often defended with statements like:

• “It’s been running for 30 years.”
• “We know how it behaves.”
• “Only one path is ever taken.”

These are operational observations — not provable guarantees.

Governance decisions cannot rely on tribal knowledge, runtime habits, or undocumented assumptions.

A provability boundary is not about whether the system usually behaves correctly. It is about whether behavior can be proven.

ALTER and Modernization Failure Modes

Automated migration and refactoring tools routinely mishandle ALTER because they must assume a fixed control-flow graph.

Common failure modes include:

• Incorrect path elimination
• Dead-code removal that removes live logic
• Incorrect translation of conditional behavior
• Hidden regression paths that only appear under rare runtime states

These failures are not bugs in the tools. They are the inevitable result of attempting to prove what cannot be proven.

Why Authority Must Refuse When ALTER Is Present

Issuing a GO decision in the presence of ALTER would require assuming that only certain runtime paths occur.

That assumption cannot be derived from source artifacts.

Under a strict governance context — Production · Regulated · High — authority must therefore refuse.

This refusal is not a judgment of code quality. It is an acknowledgment of epistemic limits.

What Governance Teams Should Do Instead

When ALTER is detected, institutions typically have three defensible options:

1. Isolate the affected modules and exclude them from automated transformation
2. Refactor to eliminate ALTER prior to modernization
3. Accept refusal and document the boundary explicitly in governance records

What is not defensible is pretending the boundary does not exist.

ALTER statements represent one class of provability boundary. Other boundary types include dynamic CALL resolution and CICS error-handling omissions.

How This Research Is Used in Authority Records

When an ALTER statement appears in an evidence bundle, authority records cite this page as the public definition of why provability terminates.

This ensures refusal is grounded in published criteria, not discretionary judgment.