It is only necessary to statically link part of the application to the application program (start LLM, see the openUTM manual “Using UTM Applications on BS2000 Systems”). The other parts of the application program must then be available in the form of dynamically loadable load modules.
As early as the KDCDEF generation you must specify at what point in time you want to load the application parts that are not to statically linked, and to which part of the memory they are to be loaded. You also specify which program units are to be exchangeable during live operation.
The individual load modules of the application must be generated with LOAD-MODULE statements for BLS implementation. You also specify when the module is to be loaded and to where. The sequence with which you generate the load modules determines the sequence in which the load modules are loaded (see LOAD-MODULE statement in section "LOAD-MODULE - define a load module (BLS, BS2000 systems)" and in the openUTM manual “Using UTM Applications on BS2000 Systems”, loading modules).
The assignment of objects (program units and shareable data areas) to load modules is likewise defined in the generation. In the PROGRAM and AREA statements in which program units or shareable data areas are generated, the name you assigned to the associated load module in the LOAD-MODULE statement must be specified in the LOAD-MODULE operand.
openUTM cannot verify whether the assignment defined with the LOAD-MODULE statement and the LOAD-MODULE operand in the PROGRAM and AREA statements corresponds to the actual division of the load modules in the libraries. When dynamically loading the load modules, openUTM relies on the specifications made in the generation. You must therefore ensure that the link procedures you use for the individual parts of the application program correspond with the specifications made in the generation. Otherwise, openUTM cannot guarantee that a required program will be loaded in the working memory with a particular load module.
The load modules are described at generation in the following manner:
| LOAD-MODULE statement in section "LOAD-MODULE - define a load module (BLS, BS2000 systems)" |
lmodname
Name of the load module. This name is used to assign objects to load modules during generation (program units, areas).
For load modules, you must only specify the names of OMs or LLMs. For performance reasons, openUTM does not support dynamic loading using CSECT or ENTRY names.
LOAD-MODE=
Specifies when a load module is to be loaded, and specifies the memory area to which it is to be loaded. The load modules can be loaded in the standard context to the local task memory, to a common memory pool or to the system memory.
The parts of the application program can be:
Linked statically to the application program (LOAD-MODE=STATIC)
The part of the application program that is loaded to the standard context of the application using the command
START-EXECUTABLE-PROGRAMorLOAD-EXECUTABLE-PROGRAM .Dynamically loaded to the standard context of the local task memory when the application is started (LOAD-MODE=STARTUP).
These should be program units that are continuously required by the UTM application, or which contain external references to shareable parts of the application.
Loaded to the standard context of the local task memory at the first call (LOAD-MODE=ONCALL)
These should be program units that are not continuously required by the application.
Loaded to a common memory pool (LOAD-MODE=(POOL,poolname,...))
The common memory pool must be generated with a MPOOL statement (see "Shared code in common memory pools").
The program units that should be loaded to the common memory pool are those that are required by all processes of a UTM application, and which are shareable, for example, the shareable parts of your program unit or also formats or data areas.
If an LLM contains public and private slices, the public slice is loaded in a common memory pool and the private slice is loaded in the standard context in the local task memory. You can specify whether the non-shareable part is to be loaded when the application is started (LOAD-MODE=(POOL, pool name, STARTUP)) or only then when that program unit is called (LOAD-MODE=(POOL, pool name, ONCALL)). For more information about the generation of shared code see also "Generating shared code and common memory pools".Loaded to the system memory as a non-privileged subsystem.
These application parts must be loaded to the system memory by the BS2000 system administrator before the application is started.
The private slice of a shareable part contained in nonprivileged subsystems can be linked to the static part of an application program, either when the application is started or the first time it is called.
How to generate the non-shareable parts is described in the section "Shared code in system memory".
LIB=
Specifies the library from which the load module is to be loaded
You can specify object module libraries (OML) or program libraries (PL) which contain type R or L elements.
VERSION=
Specifies 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 specification of the version to define which version of an element is to be loaded.
ALTERNATE-LIBRARIES=
Specifies 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.
openUTM suppresses the BLS autolink function when loading dynamically and when exchanging programs, if you specify ALTERNATE-LIBRARIES=NO. The load module then must only have open external references to program components that already exist in the working memory when this module is loaded.
For load modules that are generated using POOL or STARTUP, the sequence of the LOAD-MODULE statements at generation is critical for the resolving of open external references at loading. The sequence with which you generate the load modules determines the sequence in which the load modules are loaded.ALTERNATE-LIBRARIES=YES ensures that runtime system modules that are also required are dynamically linked when an exchange is made. The autolink function may 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.
Modules that are neither program units of the application program nor data areas (AREA) (e.g. the modules of the runtime systems of the programming languages) need not be declared as dynamically loaded modules with the KDCDEF generation tool, even if these modules are not linked statically. You can statically link these modules to larger load modules (LLM) and need only generate the name of the load module in the LOAD-MODULE statement.
The assignment of objects (PROGRAM, AREA statement) to load modules (LOAD-MODULE statement) is also defined in the generation.
| AREA statement in section "AREA - define additional data areas" |
LOAD-MODULE=
Name of the load module (lmodname in the LOAD-MODULE statement), to which the program is linked.
Program units, modules, and data areas must be linked statically to the application program if the load module to which they are assigned was generated with LOAD-MODE=STATIC or if they are not assigned to any load module.
The administration modules (e.g the KDCADM administration program) are to be statically linked to the start LLM or to one of their own load modules. This load module must be loaded when the application is started (LOAD-MODE=STARTUP). The same applies to the START, SHUT, INPUT and FORMAT event exits and the BADTAC, MSGTAC and SIGNON event services.
If specifications for objects in the statements AREA, LOAD-MODULE, MPOOL, PROGRAM and TAC are modified in the generation, only one new KDCFILE need be created. The next application start must then be based on the new KDCFILE.