Only part of the application need to be linked statically to the application program (Start-LLM, see section "Linking the application program"). The other parts of the application must then be made available in the form of dynamically reloadable load modules.
These load modules can be individual object modules (OM), which are provided in an object module library (OML) or a program library as type R elements, or link load modules (LLM) generated with BINDER, which are provided in a program library as type L elements. Groups of objects can be statically linked to LLMs using BINDER, see section "Linking LLMs".
During KDCDEF generation, the individual load modules of the application must be generated with LOAD-MODULE statements. The assignment of objects (program units and shareable data areas) to load modules is likewise defined in the UTM generation (operand LOAD-MODULE in the PROGRAM and AREA statements).
You must define the following for the load modules during KDCDEF generation:
When the load modules are to be loaded
For program units, i.e. modules generated with the PROGRAM statement, you can choose between the start time of the application and the call time of the program unit.
Non-shareable program units can be linked statically to the application program, loaded dynamically as a load module at the application start, or loaded as a load module at the time the program unit is called.
The non-shareable part (private slice) of a shareable part (public slice) contained in a common memory pool can likewise either be loaded dynamically at the application start or not loaded until the program unit is called.
The private slice of a public slice contained in nonprivileged subsystems can alternately be linked to the static part of the application program.
Modules and data areas generated with the AREA statement must either be linked statically to the application program or not loaded dynamically until the application starts, because access to these application parts is not controlled by openUTM.
The libraries from which the load modules are to be loaded
You can specify object module libraries (OML) or program libraries (PL) which contain type R or L elements.
Which version of a load module is to be loaded
A program library can contain several versions of an element at the same time. You use the version specification to define which version of an element is to be loaded.
in which storage area the load modules are to be loaded
A load module can either be loaded in a common memory pool or in the standard context of the application. The standard context contains the statically linked part of the application program, which was loaded with the command START-EXECUTABLE-PROGRAM (LOAD-EXECUTABLE-PROGRAM), as well as the parts of the application program that were not loaded in common memory pools or in the system memory.
If an LLM contains public and private slices, the public slice can be loaded in a common memory pool and the private slice can be loaded in the standard context in the local task memory.
Whether autolink is to be used for linking
The shareable parts of the load module are always loaded without using the Autolink function. You can control whether or not the Autolink function is to be used for loading with the LOAD-MODULE statement.
Suppressing the autolink function of BLS when loading and when exchanging programs speeds up the load procedure for load modules and avoids inconsistencies in the loaded application program. In this case, the load modules must only have open external references to program components that already exist in the working memory when this module is loaded.
If autolink is used for loading, the additionally required modules are linked when the load module is loaded.The autolink function should only be used for modules of the runtime system but must not be used for user-specific modules because modules loaded with autolink are not unloaded in a subsequent exchange.
The assignment of objects (PROGRAM, AREA statement) to load modules (LOAD-MODULE statement) is also defined in the UTM generation. openUTM cannot verify whether the assignment defined with KDCDEF corresponds to the actual division of load modules in the libraries. In a program exchange, openUTM relies on the specifications made in the UTM generation.
The sequence with which you generate the load modules determines the sequence in which the load modules are loaded. If load modules generated with LOAD-MODE=(POOL, poolname, STARTUP) or LOAD-MODE=STARTUP are loaded without the BLS autolink function, the generation sequence is decisive for the resolution of unresolved external references when loading.
 | Detailed information on generating the load modules can be found in the openUTM manual “Generating Applications”. |
Notes on program exchange
When generating the load modules, you define which program components can be exchanged at a later stage. The following must be noted here:
Program components that can subsequently be exchanged must not be statically linked into the application program nor loaded into global application common memory pools or the system memory.
BLS only supports the unloading of program components that were loaded in one load procedure. For example, if you want to exchange a group of modules, you must provide these modules as an LLM or OM. If you want to exchange a single module, this module can be provided as an LLM or OM and then cannot be linked with other modules.
A load module that contains the KDCADM administration program, the event exits START, SHUT, INPUT and FORMAT, or the event services BADTAC, MSGTAC and SIGNON, must not be exchanged during operation.
In an update generation, the current version numbers of the exchanged load modules are by default transferred from the old KDCFILE to the new KDCFILE if necessary.