Explain Subroutines: CALL, Static vs Dynamic in IBM Mainframes

8 / 60

COBOLintermediate

Subroutines: CALL, Static vs Dynamic

Distinguish static and dynamic CALL in COBOL and understand the tradeoffs each brings to modularity and deployment.

One COBOL program calls another with CALL. Whether the called program is bound in at link time or found at run time changes how you deploy.

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

Static: the name is a literal.

    CALL 'SUBPGM' USING WS-PARM

The binder copies the subprogram's object code into the caller's load module. At run time there is nothing to look up — the code is already there.

Dynamic: the name is a variable.

    MOVE 'SUBPGM' TO WS-PGM-NAME
    CALL WS-PGM-NAME USING WS-PARM

The module is located and loaded at run time, from the library concatenation in STEPLIB or JOBLIB.

The trade.

    static    faster; one self-contained load module.
              Every caller must be re-link-edited when the
              subprogram changes.
    dynamic   small runtime lookup; the subprogram is deployed
              independently. Callers pick up the new version
              on the next load.

The interview question is about blast radius. "You fix a bug in a subroutine called by 200 programs. What has to happen?"

With static calls: all 200 must be re-link-edited and redeployed. Miss one and it keeps running the old code, indefinitely, with nothing to indicate it.

With dynamic calls: replace one load module in the library. All 200 pick it up next time they load it.

That difference is why widely-shared utilities are normally dynamic.

The risk dynamic brings is library order. The module is found by searching the concatenation in order, so an old copy sitting in an earlier library wins:

    //STEPLIB DD DSN=TEST.LOADLIB,DISP=SHR     <- old version found here
    //        DD DSN=PROD.LOADLIB,DISP=SHR     <- the fix is here, unused

Nothing reports this. The program runs, using the wrong version, and the symptom is that a fix which was definitely deployed had no effect. Controlling concatenation order is the operational discipline dynamic calling requires.

Parameters are passed by reference. The subprogram receives the address, so changes it makes are visible to the caller:

    LINKAGE SECTION.
    01  LS-PARM  PIC X(100).
    PROCEDURE DIVISION USING LS-PARM.

There is no by-value option in the classic form, which means a subprogram can modify anything it is given — deliberately or by accident.

What the interviewer is probing.1. "What is the difference between a static and dynamic CALL?" Probing: the central point. Stalls: "Speed." Moves up: static links the subprogram into the load module at bind time; dynamic resolves it at run time, so it can be changed without relinking the caller.

2. "Which would you choose and why?" Probing: judgement. Stalls: "Static is faster." *Moves up:* dynamic for widely-used shared routines so one fix does not require relinking dozens of programs; static where call overhead matters in a tight loop.

3. "What does CANCEL do?" Probing: the detail. Stalls: "Stops the program." Moves up: it releases a dynamically called program so the next CALL gets a fresh copy with reinitialised WORKING-STORAGE.

4. "What is the trap with WORKING-STORAGE in a called program?" Probing: the subtle bug. Stalls: "None." Moves up: it persists between calls, so a routine that assumes initial values works the first time and misbehaves afterwards.