The name of a subprogram can be specified in the CALL statement either as a literal or as the identifier of a data item that contains the subprogram name or subprogram address. Depending on the kind of subprogram call, a program system is linked and loaded in different ways.
Subprogram call “CALL literal” or program address identifier “ADDRESS OF PROGRAM literal”
The name of the subprogram is already defined at compilation time. The compiler sets up external references to these subprograms; these are resolved by the relevant linkage editor in subsequent linkage runs. If a program system contains only calls in the form “CALL literal” or “ADDRESS OF PROGRAM literal”, it may be linked into a permanent or temporary executable run unit and loaded subsequently, as described in chapter "Linking, loading, starting".
Subprogram call “CALL identifier” or program address identifier “ADDRESS OF PROGRAM identifier”
The name of the subprogram need not be known before runtime (e.g. upon input at the terminal). For subprograms called as required by means of “CALL identifier” and program address identifier “PROGRAM ADDRESS identifier” there are no external references; they are therefore loaded dynamically by DBL during program execution. Program systems with subprograms of this kind can only be run in one of the following ways:
Use DBL to dynamically link the modules generated during the compilation, and dynamically load the subprograms without external references (in the main program).
Use TSOSLNK to create a prelinked module which contains the main program as well as the subprograms with external references. Call the prelinked module with DBL and dynamically load the subprograms without external references (in the main program).
Use BINDER to (pre-)link one or more link-and-load modules (LLMs). Then use DBL to call the (prelinked) LLM or the LLM containing the main program, and dynamically load the subprograms without external references (in the main program).
Generally, before calling DBL, the following assignment should be made:
/ADD-FILE-LINK BLSLIBnn,runtime-library
for the Common Run-Time Environment (CRTE), which includes the COBOL runtime system (the library SYSLNK.CRTE.PARTIAL-BIND may not be used for this purpose; see the “CRTE User Guide” [2]).
In addition, the the following assignment must be made:
/ADD-FILE-LINK COBOBJCT, library
for a library which contains the subprograms to be dynamically loaded.
Note that the link name BLSLIBnn is only effective if
RUN-MODE=ADVANCED(ALTERNATE-LIBRARIES=YES)
is specified in the invocation command for DBL (see section "Dynamic linking and loading using DBL").
If a load unit contains unresolved weak external references WXTRNSs (which is the case, for example, when the subprogram contains files with a different file organization than those in the main program), then the operands UNRESOLVED-EXTERNS=DELAY and LOAD-INFORMATION=REFERENCES must be specified:
RUN-MODE=ADVANCED (ALTERNATE-LIBRARIES=YES, UNRES-EXT=DELAY, LOAD-INF=REF
Names of link-and-load modules (LLMs) can be specified in CALL, CANCEL and ADDRESS OF PROGRAM as identifiers with a length of up to 30 characters. For object modules the program names must not exceed eight characters in length. In the case of CANCEL identifier statements for programs in object module format, the first seven characters of these names must be unique in the run unit, and the eighth character must not be a hyphen ‘-‘.
Example 13-1
Linking and loading techniques for program systems containing dynamically loadable subprograms
SUBPR1 is called only in the form “CALL literal”.
SUBPR2 is called only in the form “CALL identifier”.
SUBPR3 is called in either way.
This means that external references are set up for SUBPR1 and SUBPR3; SUBPR2 is loaded dynamically.
The ways of initiating the program run for this program constellation are shown below.
The individual programs are stored as object modules under the element names MAINPROG, SUBPR1, SUBPR2 and SUBPR3 in the library USER-PROGRAMS.
1. Using DBL (dynamic linking)
/ADD-FILE-LINK BLSLIB00,$.SYSLNK.CRTE —————————————————————————————————(1) /ADD-FILE-LINK COBOBJCT,USER-PROGRAMS —————————————————————————————————(2) /START-PROGRAM *MODULE(LIB=USER-PROGRAMS,ELEM=MAINPROG,- ————————————(3) /RUN-MODE=ADVANCED(ALT-LIB=YES,UNRES-EXT=DELAY,- /LOAD-INF=REFERENCES))
(1) | Assigns the runtime library. |
(2) | Assigns the library from which subprogram SUBPR2 will be dynamically loaded. |
(3) | Calls the object module containing the main program MAINPROG. DBL searches the library specified here (USER-PROGRAMS) to resolve the external references to SUBPR1 and SUBPR3. |
2. Using TSOSLNK (linking prelinked modules)
/START-PROGRAM $TSOSLNK MODULE PRLNKMOD,LET=Y,UNSAT=N, LIB=MODUL.LIB ——————————————————————————(1) INCLUDE MAINPROG,USER-PROGRAMS ————————————————————————————————————————(2) RESOLVE,USER-PROGRAMS —————————————————————————————————————————————————(3) LINK-SYMBOLS *KEEP ————————————————————————————————————————————————————(4) END /ADD-FILE-LINK BLSLIB00,$.SYSLNK.CRTE —————————————————————————————————(5) /ADD-FILE-LINK COBOBJCT,USER-PROGRAMS —————————————————————————————————(6) /START-PROGRAM *MODULE(LIB=MODUL.LIB,ELEM=PRLNKMOD,- ————————————————(7) /RUN-MODE=ADVANCED(ALT-LIB=YES,UNRES-EXT=DELAY,- /LOAD-INFO=REFERENCE))
(1) (2) | The prelinked module PRLNKMOD is stored in the MODUL.LIB library. Links in the MAINPROG module from the USER-PROGRAMS library. |
(3) | Links in the USER-PROGRAMS library to resolve external references to SUBPR1 and SUBPR3. |
(4) | Symbols for the entry points and the program segments for subsequent execution under DBL are kept visible by means of this statement. |
(5) | Assigns the runtime library. |
(6) | Assigns the library from which subprogram SUBPR2 will be dynamically loaded. |
(7) | Calls the prelinked module PRLNKMOD. |
3. Using BINDER (linking LLMs)
Unlike TSOSLNK, BINDER keeps all external references and entry points visible by default; this is essential for the succeeding DBL run.
Moreover, using BINDER enables external references to remain unresolved. This means that the runtime system does not have to be linked in. This is an advantage if a shareable runtime system is to be used for program execution.
a) Generating a single link-and-load module
/START-PROGRAM $BINDER //START-LLM-CREA PRLNKMOD———————————————————————————————————————————————(1) //INCLUDE-MODULES LIB=USER-PROGRAMS,ELEM=MAINPROG———————————————————————(2) //INCLUDE-MODULES LIB=USER-PROGRAMS,ELEM=SUBPR2—————————————————————————(3) //RESOLVE-BY-AUTOLINK LIB=USER-PROGRAMS—————————————————————————————————(4) //SAVE-LLM LIB=MODUL.LIB————————————————————————————————————————————————(5) //END /ADD-FILE-LINK BLSLIB00,$.SYSLNK.CRTE ——————————————————————————————————(6) /START-PROGRAM *MODULE(LIB=MODUL.LIB,ELEM=PRLNKMOD,- —————————————————(7) /RUN-MODE=ADVANCED(ALT-LIB=YES,UNRES-EXT=DELAY,- /LOAD-INFO=REFERENCE))
(1) (2) | Creates a link-and-load module named PRLNKMOD. Explicitly links in the main program module MAINPROG from the USER-PROGRAMS library. |
(3) | Explicitly links in the module SUBPR2 from the USER-PROGRAMS library in order to avoid dynamic loading. This makes it unnecessary to assign the USER-PROGRAMS library with the link name COBOBJCT in the ensuing link-and-load operation. |
(4) | Links in all other modules required (SUBPR1, SUBPR3) from the USER-PROGRAMS library. |
(5) | Stores the generated link-and-load module as a type L element in the program library MODUL.LIB. |
(6) | Assigns the runtime library. |
(7) | Calls the link-and-load module PRLNKMOD. |
b) Converting object modules into single link-and-load modules
/START-PROGRAM $BINDER ... //START-LLM-CREATION INTERNAL-NAME=MAINPROG (1) //INCLUDE-MODULES LIB=USER-PROGRAMS,ELEM=MAINPROG | //SAVE-LLM LIB=MODULE.LLM (1) ... //START-LLM-CREATION INTERNAL-NAME=SUBPR1 (2) //INCLUDE-MODULES LIB=USER-PROGRAMS,ELEM=SUBPR1 | //SAVE-LLM LIB=MODULE.LLM,ENTRY-POINT=SUBPR1 (2) ... //START-LLM-CREATION INTERNAL-NAME=SUBPR2 (3) //INCLUDE-MODULES LIB=USER-PROGRAMS,ELEM=SUBPR2 | //SAVE-LLM LIB=MODULE.LLM,ENTRY-POINT=SUBPR2 (3) ... //START-LLM-CREATION INTERNAL-NAME=SUBPR3 (4) //INCLUDE-MODULES LIB=USER-PROGRAMS,ELEM=SUBPR3 | //SAVE-LLM LIB=MODULE.LLM (4) //END ... /ADD-FILE-LINK BLSLIB00,$.SYSLNK.CRTE ————————————————————————————————— (5) /ADD-FILE-LINK COBOBJCT,MODULE.LLM ———————————————————————————————————— (6) /START-PROGRAM *MODULE(LIB=MODULE.LLM,ELEM=MAINPROG,- ————————————————— (7) /RUN-MODE=ADVANCED(ALT-LIB=YES,UNRES-EXT=DELAY,- /LOAD-INFO=REFERENCE))
(1) | Creates an LLM named MAINPROG; the name of the LLM is freely selectable. Links in the object module MAINPROG from the USER-PROGRAMS library. As the element name is omitted from the SAVE-LLM command, the name specified in the START-LLM-CREATION command is used; that is, MAINPROG. |
(2) | Creates an LLM named SUBPR1. Links in the object module SUBPR1 from the USER-PROGRAMS library. ENTRY-POINT=SUBPR1 defines this LLM as a subprogram. |
(3) | Creates an LLM named SPROG2. Links in the object module SUBPR2 from the USER-PROGRAMS library. ENTRY-POINT=SUBPR2 defines this LLM as a subprogram. |
(4) | Creates an LLM named SUBPR3. Links in the object module SUBPR3 from the USER-PROGRAMS library. As no ENTRY-POINT is specified in the SAVE-LLM command, SUBPR3 can be used both as a subprogram and as a main program. |
(5) | Assigns the runtime library. |
(6) | Assigns the library containing the LLMs by means of the link name COBOBJCT so that the unresolved external references of the previously created LLMs can be resolved. |
(7) | Calls the LLM containing the main program MAINPROG. |