For each load module to be built, SMP/E determines whether a SYSLIB allocation is required. It does this by checking the corresponding LMOD entry for a CALLLIBS subentry list. If a SYSLIB allocation is required, the allocation is done before the load module is link-edited. Each ddname in the CALLLIBS subentry list is dynamically allocated using information from the corresponding DDDEF entry, and is assigned an SMP/E-generated ddname. When the CALLLIBS subentry list contains more than one name, SMP/E allocates them as a concatenation and gives it a generated ddname. If errors occur during the SYSLIB allocation, dynamic allocation error messages are issued, and the load module is not link-edited. Any SYSMODs supplying modules for the link-edit are also failed.

The procedure for building a load module with a SYSLIB allocation (one that has CALLLIBS subentries) depends on whether the load module also has XZMOD subentries and whether the set-to zone has an UPGLEVEL subentry, as follows:

• If the load module has no XZMOD subentries and the set-to zone has an UPGLEVEL subentry, the load module will be rebuilt from scratch and saved into its true system libraries. SMP/E will not save a "base" version of the load module in the SMPLTS data set.
• If the load module has XZMOD subentries or if the set-to zone has no UPGLEVEL subentry, then the load module is built in two stages: first, a "base" version of the load module is built in the SMPLTS data set; second, the executable version of the load module is built in the target libraries.
  1. Building the "base" version of the load module. The appropriate INCLUDE statements are built:
     • If the load module does not currently exist in the SMPLTS library, an INCLUDE statement is built for each module explicitly defined in the link-edit JCLIN as being included in the load module. No INCLUDE statement is built for the load module itself.
       Note: This is done even if the executable version of the load module exists in the target libraries.
     • If the load module does currently exist in the SMPLTS data set, an INCLUDE statement is built for each module that is selected from a SYSMOD being processed and that is explicitly defined in the link-edit JCLIN as being included in the load module. In addition, an INCLUDE statement is built to include the current version of the load module from the SMPLTS library. This is done to obtain the other modules that make up the load module.

     When the "base" version of a load module is link-edited into the SMPLTS, any CHANGE and REPLACE link-edit control statements defined for the load module are passed to the link-edit utility, as well as all link-edit options defined for the load module. (No link-edit control statements other than CHANGE and REPLACE are processed.) This link-edit results in unresolved external references, which is considered normal.

  2. Building the executable version of the load module. The executable version of the load module is built in the target libraries using the load module's SYSLIB allocation (the CALLLIBS subentry list in its LMOD entry) and the "base" version of the load module from the SMPLTS data set. The only INCLUDE statement built is for the "base" version of the load module from the SMPLTS data set.
     Note:

     1. If the "base" version of the load module does not exist in the SMPLTS data set, the load module is not link-edited.
     2. A load module can reside in an executable target library before a base version of it has been built in the SMPLTS. If the load module had included cross-zone modules through the use of the LINK MODULE command, these modules are no longer included after the installation of a SYSMOD that causes the load module to be built into the SMPLTS. (Warning messages are issued to indicate this.) After the installation of such a SYSMOD, the LINK MODULE command needs to be rerun in order to include those cross-zone modules back into the load module.