Linking LLMs

All module groups in a logical relationship should be statically linked as LLMs. Such module groups include:

• parts of the runtime systems

• logically related parts of a UTM application, e.g. all program units of one or more services including conversation exits

• FHS formats including the associated program units

In order that the external references of an LLM can be resolved when this LLM is dynamically linked, the following BINDER statements must be specified when creating the LLM:

/START-LLM-CREATION    INTERNAL-NAME=int-name - ———————————————————————  (1) 
/                     ,INTERNAL-VERSION=int-vers - 
/                     ,...
/SET-EXTERN-RESOLUTION SYMBOL-TYPE=*REFERENCES - ——————————————————————  (2) 
/                     ,RESOLUTION=*STD
/SAVE-LLM          ...,ELEMENT=*INTERNAL-NAME( - ——————————————————————  (3) 
/                      VERSION=*INTERNAL-VERSION) -
/                     ,FOR-BS2000-VERSIONS=*FROM-OSD-V4(...) 

1. Here you define the name and version of the LLM, and how the LLM is saved in the library when linking is concluded.

2. The handling of unresolved external references is defined. The specified operand values are the defaults which must on no account be modified.

3. The LLM must be saved under the internal name; the format of the LLM must be correct (at least LLM format 2 as in the example).

   If a name other than the internal name is selected when saving and if LOAD-MODULE,...,ALTLIB=YES is specified when generating, openUTM cannot find the module when a program is exchanged and reports an UNBIND error (K078 UNBIND 0C010174).

Repeated elements

When statically linking LLMs, you must ensure that the incorporated elements (sub-LLMs / OMs) do not occur in several (possibly statically linked) LLMs / OMs. If this is the case, however, the external names contained in repeatedly linked modules must be masked by the BINDER statement MODIFY-SYMBOL-VISIBILITY.

Autolink function for dynamically loading load modules

The autolink function is controlled in the LOAD-MODULE statement by the operand ALTERNATE-LIBRARIES.

• ALTERNATE-LIBRARIES=NO
  switches off the autolink function of BLS. This means that for all dynamically generated load modules loaded in this way, all open references of such a load module must be resolved by the modules loaded at load time (start LLM and other load modules) and by the shared code. External references in the runtime system are always resolved for load modules comprising only C or data objects if a RESOLVE-BY-AUTOLINK to the library SYSLNK.CRTE.PARTIAL-BIND was specified when linking the start LLM.

• ALTERNATE-LIBRARIES=YES
  switches on the autolink function of BLS.
  You can use this for load modules which, when loaded and exchanged, require additional modules of the runtime system that are not yet contained in the memory. When linking, open external references are first sought in the link context and then in the shared code (see also the manual „Dynamic Binder Loader/Starter“). If external references are still unresolved after this, the library you specified in the LIB operand is searched. If a suitable definition is found, the associated module is linked and the search is terminated. Otherwise, the search is continued in the libraries to which you have set a link with the SET-FILE-LINK command before the application is started with the link name BLSLIBnn (where 00<=nn<=99). The libraries are processed in ascending order of nn.

  The handling of the runtime system modules in connection with UTM applications is described in detail on "Linking runtime systems".

The autolink mechanism should not be applied on user-specific libraries because only the load module and not the entire load unit, which also contains all modules loaded by autolink, is unloaded when a program is exchanged.

The autolink function for the start LLM can be influenced by the parameters of the command START-EXECUTABLE-PROGAM. See also the example on "Loading modules".

Example

• UTM generation and LINK statement

  UTM generation:

  LOAD-MODULE     lm-name                                        -
                  ,VERSION             = llm-version             -
                  ,LIB                 = lm-lib                  -
                  ,LOAD-MODE           = ONCALL                  -
                  ,ALTERNATE-LIBRARIES = YES 
  

  LINK statement before application start:

  /SET-FILE-LINK

  LINK-NAME = BLSLIB00,FILE-NAME = $userid.SYSLNK.CRTE.PARTIAL-BIND

  First of all, the LOAD-MODULE statement generates the load module lm-name with LOAD-MODE=ONCALL, i.e. lm-name is not loaded dynamically until a constituent program is called. In the example, lm-name should contain COBOL objects.

  To resolve open external references when loading, the library lm-lib specified in the LIB operand is first searched and then the library $userid.SYSLNK.CRTE.PARTIAL-BIND, which is assigned using the SET-FILE-LINK command.

• BINDER statements

  /START-BINDER
  //START-LLM-CREATION     INTERNAL-NAME    = llm-name             -
  //                      ,INTERNAL-VERSION = llm-version 
  //INCLUDE-MODULES        LIBRARY=user-library                    -
  //                      ,ELEMENT=program-unit-name
  //RESOLVE-BY-AUTOLINK    LIBRARY=(library1,library2..)
  //SET-EXTERN-RESOLUTION  SYMBOL-TYPE=*REFERENCES                 -
  //                      ,RESOLUTION=*STD
  //SAVE-LLM               LIBRARY=llm-library                     -
  //                      ,ELEMENT=*INTERNAL-NAME(                 -
  //                       VERSION=*INTERNAL-VERSION)              -
  //                      ,FOR-BS2000-VERSIONS=*FROM-OSD-V4(...)
  //END
  

  In this binder run, an application program unit is linked to a load module. KDCROOT is not incorporated here, e.g. because the KDCS entry remains unresolved.