UTM applications use the functionality of the BLS to load LLMs (link and load modules) and OMs (object modules). This opens up new possibilities:
When managing objects using LLMs that are subdivided into a private and a public slice.
This means that the shareable and non-shareable parts of an object generated in a compiler run can be managed in a container. This largely avoids inconsistencies when pre-linking and replacing objects.
When loading an object (program, area).
An object can be incorporated statically or loaded dynamically at the application start. In the case of program units, it is also possible to defer dynamic loading until the first call is executed.When exchanging the program.
An individual object (LLM or OM) or a statically linked group of objects (LLM or OM) can be exchanged.
Only some of the application objects need be linked statically to the application program. This part of the application program is called the start LLM and is loaded and started using the command START-EXECUTABLE-PROGRAM FROM-FILE=*LIBRARY(...). You must link in those ROOT system modules and the objects (program units, modules and data areas) in the start LLM that are not assigned to a load modue or are assigned to a load module with LOAD-MODE=STATIC.
The ROOT table module created by KDCDEF need not to be linked statically, i.e. it can be loaded dynamically at the application start.
The other parts of the application program can be made available in the form of load modules. A load module is
either a statically linked link load module (LLM) contained in a program library as a type L element,
or an object module (OM) contained in an object module library as a type R element.
For performance reasons, however, you should use BINDER to statically link all load modules to LLMs and make them available in a program library as type L elements.
When generating, you must enter precisely one LOAD-MODULE statement for each link load module and each object module that you do not link into the START-LLM statically, and thereby specify when the module is to be linked and where it is to be loaded. For more information, see the openUTM manual “Generating Applications”.
If there are unresolved external references to program units when you link the application, you can still start the application. If you cannot resolve these external references by dynamic loading, the assigned transaction codes for the application are invalid, i.e. they cannot be used.