The runtime system and ILCS modules must not be linked in when prelinked modules are linked if the prelinked modules concerned are to be linked to other objects or prelinked modules at a later time. Some particular runtime system modules such as, e.g. IT0PCD or ITCMPOVH, may only be present once in an application, otherwise the data interchange between the runtime modules will not function correctly. This does not apply for encapsulated subsystems that are described in detail in section “Encapsulated subsystems”.
The runtime system and ILCS may also not be linked statically into assembler or COBOL applications that dynamically load subroutines or main modules at runtime, since the runtime system modules would then not be found by the dynamically loaded subroutines and this would lead to a second runtime system being loaded. The following exception also applies in this case: if only encapsulated subsystems are dynamically loaded, the application can be linked completely.
Example
The following example illustrates linking and loading techniques for program systems containing dynamically loadable subprograms.
SUBPR1 is only called in the form CALL literal.
SUBPR2 is only called 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.
Using the BINDER (linking LLMs)
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.
The following example illustrates generating a single link- and-load module.
/START-PROGRAM $BINDER START-LLM-CREA GROSSMOD .....................................(1) INCLUDE-MODULES LIB=BENUTZER-PROGRAMME,ELEM=MAINPROG ........(2) INCLUDE-MODULES LIB=BENUTZER-PROGRAMME,ELEM=UPROG2 ..........(3) RESOLVE-BY-AUTOLINK LIB=BENUTZER-PROGRAMME ..................(4) SAVE-LLM LIB=MODUL.LIB ......................................(5) END /ADD-FILE-LINK BLSLIB00,$.SYSLNK.CRTE ....................... (6) /START-PROGRAM *MODULE(LIB=MODUL.LIB,ELEM=GROSSMOD,- .........(7) RUN-MODE=ADVANCED(ALT-LIB=YES,UNRES-EXT=DELAY,- LOAD-INFO=REFERENCE))
(1) | Creates a link-load-load module named PRLNKMOD. |
(2) | 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) | Assign the runtime library. |
(7) | Call the link-and-load module PRLNKMOD. |