The following rules and restrictions must be observed when dividing objects into load modules and when linking and dynamically loading objects:
The event exits START, SHUT, INPUT and FORMAT and the event services BADTAC, MSGTAC and SIGNON must not be assigned to any load module whose loading is deferred until a program unit is called, i.e. is generated with LOAD-MODE=ONCALL. The reason for this is that the event exits and event services must be available in each process of the application. If they are not, openUTM aborts the start of the process.The load modules that contain event exits and event services must not be exchanged during operation. Errors occurring during the exchange of the load modules can lead to the abnormal termination of the application.
The administration program KDCADM must not be assigned to any load module generated with LOAD-MODE=ONCALL.
The load module to which the KDCADM administration program is linked must not be exchanged.
If the administration program KDCADM is not available when the application is started, openUTM aborts the start.Data areas (AREAs) must either be statically linked to the application program, or, if possible, generated as LOAD-MODULEs with LOAD-MODE(POOL, STARTUP) or LOAD-MODE=STARTUP.
The start LLM must be made available in a program library. It must not be contained in a file.
You must specify the following operands in the START-EXECUTABLE-PROGRAM command:
/ ,DBL-PARAMETERS=*PARAMETERS( - / ,LOADING=*PARAMETERS( - / PROGRAM-MODE=*ANY - / ,LOAD-INFORMATION=*REFERENCES) - ... / ,ERROR-PROCESSING=*PARAMETERS( - / UNRESOLVED-EXTRNS=*DELAY - / ,...))
You must specify PROGRAM-MODE=*ANY if the application is to be loaded into the upper address space.
If an administration command requires a program exchange, you must explicitly specify the version of the new module to be loaded.
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.
openUTM supports a maximum of eight common memory pools with SCOPE=GROUP and eight common memory pools with SCOPE=GLOBAL.
Two UTM applications should be started under different BS2000 user IDs if possible to prevent errors that can arise due to having the same module name appear twice in a shareable section. Modules that are used by several applications are therefore to be loaded into global common memory pools or in nonprivileged subsystems.
A newly created table module can be created by exchanging a program.
The variant number of the LMS is of no significance when loading load modules with BLS.
BLS only supports the unloading of program components that were loaded in one load procedure. For this reason, program components that are to be exchangeable as separate parts must be made available in the form in which they are to be loaded and exchanged. If an individual module is to be exchanged, this module can be made available as an OM or LLM; if a group of load modules is to be exchanged, these modules must be statically linked as LLMs.
Load modules containing TCB entries must not be exchanged during operation.
Modules that are loaded dynamically using the Autolink function cannot be exchanged or unloaded. Exception: When exchanging the entire application (e.g. with KDCAPPL PROG=NEW), all parts of the application are reloaded.
FHS can not be loaded from the TASKLIB. FHS format modules can be exchanged with this version or later.
When statically linking load modules to LLMs, please note that the incorporated elements should not appear in more than one load module. Restrictions therefore apply, particularly when incorporating the runtime systems of the programming languages. For information on how to link the runtime system modules required for the application program, see section “Linking runtime systems”.