IMS DL/I Opaque Runtime

What IMS DL/I Is

IMS DL/I (Data Language/I) is a hierarchical database interface that predates relational data models. It operates through explicit calls that navigate database segments using Program Communication Blocks (PCBs).

CALL 'CBLTDLI'
  USING GU,
        PCB-ACCT,
        ACCT-SEG,
        SSA-ACCT
    

Each call mutates internal navigation state. That state is preserved across calls and influences subsequent behavior.

The Core Problem: Stateful Navigation

IMS DL/I programs do not declare a complete query or transaction outcome in a single call.

Instead, behavior emerges from:

• The sequence of DL/I calls
• The current PCB position
• The success or failure of prior calls
• Implicit parent/child traversal rules

None of this state is fully reconstructible from static source artifacts alone.

Why Static Analysis Cannot Prove DL/I Behavior

Static analysis can identify:

• Which DL/I calls exist
• Which PCBs are referenced
• Which segments are named

It cannot prove:

• The order of traversal at runtime
• The PCB position at any given call
• The complete set of segments visited
• Whether an error path was taken earlier

Why Testing Does Not Restore Provability

DL/I behavior depends on database contents, access paths, and execution order.

A test run can demonstrate one observed behavior, but cannot prove the absence of others.

Authority cannot be issued based on sampled execution paths.

Migration Failure Modes

When IMS DL/I applications are migrated or rehosted, common failures include:

• Incomplete data traversal
• Duplicate segment processing
• Silent data omission
• Incorrect parent-child association

These failures often surface only under production load or atypical data distributions.

Why Authority Must Terminate

Issuing a GO decision would require assuming that runtime navigation state behaves identically in all executions.

That assumption is not provable from source.

Under Production · Regulated · High governance context, IMS DL/I therefore constitutes a provability boundary.

Adjacent boundary types include CICS error-handling omissions and dynamic CALL resolution.

What Institutions Do When DL/I Appears

Institutions typically respond by:

1. Isolating DL/I logic from migrated components
2. Refactoring into declarative data access layers
3. Documenting refusal and narrowing scope

How This Research Is Used in Governance

Authority records reference this page as the public definition of why IMS DL/I runtime behavior terminates deterministic guarantees.

This ensures refusals are consistent, reviewable, and defensible years later.