Many applications, which are no longer being developed, use the LINK macro to dynamically load external runtime components. The migration of such runtime components from the object module to the LLM would therefore have been impossible without sacrificing compatibility, since the LINK macro runs only in the standard RUN-MODE, in which LLMs could not be processed earlier.
To enable migration without losing compatibility, the standard RUN-MODE of DBL was therefore extended so that LLMs can also be processed under certain conditions. In principle, such LLMs must have the attributes of an object module, i.e.:
it must not include any user-defined slices
the names of all included OMs must not exceed a length of 8 characters
no symbol name may be longer than 8 characters
there must not be any unresolved external reference to a symbol with a name exceeding 8 characters in length
there must not be any reference from the private LLM section to a PUBLIC symbol with a name that is longer than 8 characters
the LLM must include information on the logical structure
LLMs which have been processed with the BINDER statement MERGE-MODULES can also be loaded with the LINK macro. Merging enables symbols that are not required to be made invisible externally. The merged LLM or sub-LLM now contains only a prelinked module with one single CSECT.
Due to the differences between the standard and advanced RUN-MODEs, the number of modules that are loaded dynamically with LINK or BIND may differ considerably. Consequently, the loading behavior of both the BIND macro and the LINK macro should be observed very carefully when migrating the runtime components.