Module Format for Programs and Panels › Module Runtime Considerations › Building the In-Core Load Module Table

Building the In-Core Load Module Table

The in-core load module table (LMT) identifies the application programs and panels that are in load module format and provides their module names for the runtime environment. Whenever an application RUN loads a production program or panel for the first time or after it is reaccessed after a RELEASE statement, CA Ideal determines whether the entity is in load module format. If an entry is found, standard operating system service calls are issued, depending on the environment. If an entry is not found, a load of the program or panel is requested from the appropriate VLS library.

The contents of the LMT can be built using two sources of input:

• By scanning the MODULE dictionary entities for entries that correspond to CA Ideal application programs and panels. For each program or panel MODULE DD entity, an entry is added to the in-core LMT that identifies the program or panel name and its corresponding module name.
• By using site-maintained tables to control the contents of the LMT. This option provides two structures with CA Ideal are analogous to the CICS RDO LIST/GROUP structures.
• Application Module Table (AMT): Application Module Tables (AMTs) are physical modules/phases containing entries of programs and panels and their corresponding load module prefix. Each program and panel defined in an AMT adds an entry to the in-core LMT without requiring the presence of a module entity occurrence in the dictionary. There can be multiple AMTs in a single region. AMTs are assembled and linked with macros that CA Ideal provides. They have a naming convention of @ILMTxxx, where xxx is a name the user provides.
• @ILMLIST: @ILMLIST is a module that contains the list of AMTs to process when building the in-core LMT. @ILMLIST is assembled and linked with macros CA Ideal provides. Each region (batch or on-line) can have a separate copy of @ILMLIST, thereby allowing each region to tailor the load modules it runs.

The section following describes these two structures in more detail.

For batch, the in-core LMT is built when the first RUN command is issued. Under CICS environments, the in-core LMT is built when CICS starts, provided the program @IADPLTI was included in the PLT program startup list. If @IADPLTI is not in the PLT or in the unlikely event that the task is not successful, the user issuing the first RUN command invokes the processing to build the in-core LMT.

You can control which sources build the LMT by setting the LMTBLD parameter of the IDOPTSCB macro in the IDOPTS source (which produces the @IIDOPTS load module that controls CA Ideal site options). Enter the LMTBLD parameter on the FUNC=START statement in the IDOPTSCB macro. You can assign the following values to the LMTBLD parameter:

• DD-Builds the in-core LMT using entries from the @ILMLIST module and entries found in the dictionary module table.
• NO-Builds the in-core LMT from processing @ILMLIST only.

The building of the in-core LMT in all environments begins with the loading of @ILMLIST. If @ILMLIST contains entries, the in-core LMT is built based on the contents of each AMT table specified in @ILMLIST. If @ILMLIST is empty, the in-core LMT is empty at this point.

Under CICS, if LMTBLD=DD has been specified, the in-core table will be updated to include any module entries in the dictionary that do not exist in the in-core LMT.

In batch where LMTBLD=DD, each time a program or panel is accessed and is not found in the in-core LMT, the dictionary is accessed to determine if a module occurrence is present. If a module occurrence is found, it is added to the in-core LMT.

The in-core LMT is always built, but can be empty. An empty in-core LMT is built when @ILMLIST is empty and either LMTBLD=NO or there are no module entity occurrences in the dictionary. When both of these conditions are true, CA Ideal uses only VLS members in the environment.