The load structure of an application definitively determines the time required to start the first task and the follow-up tasks of an application. It also defines which program components can be exchanged at a later stage in the application run. For this reason, you should note the following recommendations:
The statically linked part of the application program to be loaded with the START-EXECUTABLE-PROGRAM command (start LLM) should be kept as small as possible. It must contain the ROOT system modules and the runtime modules required by the system modules of KDCROOT.
The administration modules (e.g the KDCADM administration program) are to be statically linked to the start LLM or must be loaded when the application is started, i.e. it must be generated with LOAD-MODULE ...,LOAD-MODE=STARTUP. Self-written administration programs should be loaded like the loading module KDCADM when starting the application, i.e. they should be statically bound to the start LLM like the loading module KDCADM or loaded when starting the application. A load module containing the administration program KDCADM must not be exchanged during operation. Therefore you must not connect self-written administration programs, which should be exchangeable, with the KDCADM.
The START, SHUT, INPUT and FORMAT event exits and the BADTAC, MSGTAC and SIGNON event services 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, i.e. it must be generated with LOAD-MODULE ...,LOAD-MODE=STARTUP. It must not be exchanged during operation because errors occurring during the exchange can lead to the abnormal termination of the application.
Program components that are to be exchanged at a later stage must not be linked statically or loaded into global application common memory pools or into the system memory.
Program components that are required by more than one application should be shareable, e.g. should be loaded as a nonprivileged subsystem.
All other application parts that are shareable should be pre-linked to form a load module that should be loaded into a common memory pool. If several load modules with shareable program components are required for some reason, these should nevertheless be loaded into only one common memory pool.
Many compilers allow you to save the shareable and the non-shareable module together in one LLM. This simplifies the administration of the modules, as both parts are always located in one container. In this case, the shareable and non-shareable parts should not be statically linked separately, rather the LLMs with public and private slices, as created by the compiler, should be statically linked in one or more LLMs.
openUTM loads the public slice of this type of LLM into a memory pool and loads the private slice into the local task memory at the application start or when a program from the LLM is called, if you generate the LLM with
LOAD-MODULE ..., LOAD-MODE=(POOL,...,STARTUP) or LOAD-MODE= (POOL,...,ONCALL).Program components that are only required occasionally should be generated such that they are not loaded dynamically until they are called (LOAD-MODULE ...,LOAD-MODE=ONCALL).
This shortens the start phase. These load modules should be statically linked in small logical units, because it takes less time to load small modules that large ones.Application parts that are logically related should be statically linked in a load module. These may be program components that refer to each other or which belong to a sequence of program unit runs in a service.
All program components that are to be loaded dynamically should be statically linked as LLM. This considerably speeds up the start of the application and the loading of load modules, because the dynamic binder loader (DBL) can process LLMs much more efficiently than OMs.
The number of load modules loaded when the application program starts (LOAD-MODE=STARTUP or LOAD-MODE=(POOL,...,STARTUP) should be kept as small as possible. For this reason, only the parts of the application that are frequently required should be generated with STARTUP.
Since it takes less time to load a small number of large load modules than a large number of small load modules, these parts of the application program should be statically linked to larger load modules.Only one local application common memory pool should be defined (MPOOL ..., SCOPE=GROUP). A number of statically linked load modules can be loaded into this pool. This reduces the time required to set up and load the common memory pools and thereby minimizes the time needed to start the application.
OMs and LLMs should be made available in different program libraries because this optimizes the BLS search algorithm.
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.
CAUTION!
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 UTM 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 UTM generation. Otherwise, openUTM cannot guarantee that a required program will be loaded in the working memory with a particular load module.