Static and dynamic CALL, CANCEL and ON EXCEPTION

How does the called program actually get into memory? There are two answers, and which one your shop uses affects how changes are deployed.

Static calls

With a static call, the subprogram's object code is link-edited into the caller's load module. One load module contains both. The call is fast and can't fail at run time, but if the subprogram changes, every program that includes it must be link-edited again to pick up the change.

On IBM Enterprise COBOL, CALL "LITERAL" is static when the caller is compiled with the NODYNAM option.

Dynamic calls

With a dynamic call, the subprogram is its own load module. The first CALL finds it in the load libraries and loads it; later calls reuse the loaded copy. Replace the module in the library and the next run picks up the new version without touching any caller. Most large shops call their shared routines dynamically for exactly that reason.

A call is dynamic when:

• the caller is compiled with DYNAM and uses CALL "LITERAL", or
• the program name is in a data item: CALL WS-PGM. This is always dynamic, because the name isn't known until run time.

CALL identifier lets a program pick the routine from its data: one rating module per insurance product, one validation module per country. GnuCOBOL, which runs your code here, loads separately compiled subprograms dynamically for both forms.

CANCEL

CANCEL "NAME" (or CANCEL WS-PGM) releases a dynamically called program. The next CALL loads a fresh copy, so its WORKING-STORAGE is back to its VALUE clauses. You can list several names in one CANCEL. Cancelling a program that was never called does no harm.

ON EXCEPTION

If a dynamic CALL can't find the module, the run unit fails. GnuCOBOL prints libcob: error: module 'NOSUCH' not found; on z/OS the step abends with S806. When the program name comes from data, that is a real possibility, so trap it:

       IDENTIFICATION DIVISION.
       PROGRAM-ID. DYNDEMO.
       DATA DIVISION.
       WORKING-STORAGE SECTION.
       01  WS-PGM           PIC X(8).
       PROCEDURE DIVISION.
           MOVE "COUNTER" TO WS-PGM
           CALL WS-PGM
           CALL WS-PGM
           CANCEL WS-PGM
           CALL WS-PGM
           MOVE "NOSUCH" TO WS-PGM
           CALL WS-PGM
               ON EXCEPTION
                   DISPLAY "CANNOT LOAD " WS-PGM
           END-CALL
           DISPLAY "STILL RUNNING"
           STOP RUN.

       IDENTIFICATION DIVISION.
       PROGRAM-ID. COUNTER.
       DATA DIVISION.
       WORKING-STORAGE SECTION.
       01  WS-N             PIC 9(3) VALUE 0.
       PROCEDURE DIVISION.
           ADD 1 TO WS-N
           DISPLAY "COUNTER CALL " WS-N
           GOBACK.
       END PROGRAM COUNTER.
       END PROGRAM DYNDEMO.

COUNTER CALL 001
COUNTER CALL 002
COUNTER CALL 001
CANNOT LOAD NOSUCH
STILL RUNNING

NOT ON EXCEPTION runs when the call did work. Close the statement with END-CALL.

A trap: DISPLAY has ON EXCEPTION too

DISPLAY accepts its own ON EXCEPTION and NOT ON EXCEPTION phrases. Write this:

           CALL "NOSUCH"
               ON EXCEPTION
                   DISPLAY "MISSING"
               NOT ON EXCEPTION
                   DISPLAY "LOADED"
           END-CALL

and the compiler attaches NOT ON EXCEPTION to the DISPLAY, not the CALL. The program prints MISSING and LOADED. Put the work in paragraphs (PERFORM 3000-NO-MODULE), or close the DISPLAY with END-DISPLAY.