Processing link-edit steps

Link-edit steps must not be sensitive to the order of execution of other link-edit steps either for the same FMID or for another, conditionally coexistent FMID. No elements to be included in a link-edit step should be derived from the output of another link-edit step. Also, if multiple load modules and target libraries are involved, SMP/E organizes the link-edit steps for the most efficient invocations of the link-edit utility (which might not be in the same order as in the JCLIN data).

For example, suppose a product consists of a base function and a dependent function. The dependent function conditionally coexists with the base function; it can be installed with the base function, but is not a prerequisite for the base function. The base function must have its own JCLIN data that completely describes the elements it contains, because a user may choose to install the functions together or separately. If the base function is installed separately, its JCLIN data cannot contain a link-edit step that includes elements from the dependent function, because those elements are not yet available.

ALIAS statement

To ensure that SMP/E can process your link-edit ALIAS control statements, you must address the following considerations:

• General considerations
  • An ALIAS control statement can span any number of 80-byte records.
    Note:

    1. If you assign a load module residing in a PDSE an alias value greater than eight characters, you cannot later use the ++DELETE statement to delete that alias value (and not the associated load module). To delete such an alias value without deleting the load module, you need to resupply JCLIN to define the load module without providing an ALIAS statement for the alias value to be deleted. Make sure to also include a ++MOD statement for a module in the load module to force SMP/E to relink the load module.
    2. If the set of alias values (or symbolic links) for an existing load module changes, SMP/E does not remove the original set of alias values (or symbolic links) from a PDS target library or a UNIX file system. If it is important that these original values be removed, you can delete them by either:
       1. Using the ++DELETE MCS to remove the specific alias value or symbolic link that is not needed, or
       2. Using the ++DELETE MCS to remove the entire load module, using JCLIN to redefine the load module with the correct set of alias values and symbolic links, and then rebuilding the load module by supplying all of its modules.
  • Column 1 of all 80-byte records composing an ALIAS control statement must contain a blank (X'40').
  • The data for the first 80-byte record of an ALIAS control statement must start in column 2 or later and end anywhere up to and including column 71.
  • The control statement type (ALIAS) must be followed by at least 1 blank (X'40').
  • The control statement type (ALIAS) must be in uppercase.
  • Columns 73 through 80 of an 80-byte record are ignored.
  • An alias value can be from one to 1023 characters.
  • An alias value can be composed of characters in the range X'41' through X'FE'.
    Note: Although the binder also accepts characters X'0E' (shift-out character) and X'0F' (shift-in character), SMP/E does not accept them.
  • An alias value can be enclosed in single apostrophes. It must be enclosed in single apostrophes when:
    • It contains a comma. For example:

        ALIAS 'If_the_alias_contains_a_comma,_enclose_it_in_apostrophes.'

    • It contains an apostrophe. For example:

        ALIAS 'It''s_the_apostrophe_in_"it''s"_that_necessitates apostrophes.'

    • It contains a left parenthesis. For example:

        ALIAS 'A_left_parenthesis_-(-_means_enclose_it_in_apostrophes.'

    • It contains a right parenthesis. For example:

        ALIAS 'A_right_parenthesis_-)-_means_enclose_it_in_apostrophes.'

  • If an apostrophe is part of the alias value (not a delimiter), two apostrophes need to be specified in the appropriate location in the alias value. These two apostrophes count as two characters in the 1023-character limit for an alias value. Here is an example:

     ALIAS 'It''s_the_quote_that_makes_apostrophes_necessary.'

  • The single apostrophes used to enclose an alias value do not count as part of the 1023-character limit for an alias value. For example, the alias value in the following example contains 10 characters:

     ALIAS  'Only_ten!!'

  • SMP/E uses the alias value exactly as is. SMP/E does not try to enforce any rules the binder may be using as a result of the CASE execution parameter.
• Continuation records
  • Column 72 of a given 80-byte record must be a nonblank character if the control statement is continued onto the next 80-byte record. The character in column 72 denotes only continuation and is never part of an alias value.
  • The data for continuation records (80-byte records 2 through n of an ALIAS control statement) can start in column 2 or later and end anywhere up to and including column 71 (for example, if multiple aliases are being specified).
    The data for a continuation record must start in column 2 if it is part of an alias value that is being continued from the previous 80-byte record. An alias value that is continued from one 80-byte record to another 80-byte record must meet these requirements:

    • Extend through column 71 of the first 80-byte record
    • Start in column 2 of the next 80-byte record
    • Have a nonblank continuation character in column 72
    An example:

             1         2         3         4         5         6         7         8
    ----+----0----+----0----+----0----+----0----+----0----+----0----+----0----+----0
     ALIAS          This_is_a_very_long_value_that_is_continued_to_the_next*
     _card!

• Entry points
  One format of the ALIAS statement supported for the binder allows an alternative entry point to be specified into a load module. If this format is used, each alias name with an associated entry point must be specified on its own 80-byte record, with a separate ALIAS statement; no other aliases should be specified on that statement. If multiple alias values of this format are specified on a single ALIAS control statement, only the first is recognized; the rest are ignored.

  Note: When this form of the ALIAS control statement is used, the maximum length for an alias value is 61 characters.
  Suppose that a load module has the following aliases: ALA1, ALA2, ALA3, and ALA4. ALA1 and ALA2 are associated with entry point names ENTRYPT1 and ENTRYPT2, respectively.

  • Here are examples of how the aliases should be specified:

     ALIAS ALA1(ENTRYPT1)
     ALIAS ALA2(ENTRYPT2)
     ALIAS ALA3
     ALIAS ALA4
    or
     ALIAS ALA3,ALA4

  • Here are examples of how the aliases should not be specified:

     ALIAS ALA1(ENTRYPT1),ALA2(ENTRYPT2),ALA3,ALA4
    or
     ALIAS ALA1(ENTRYPT1),ALA3
     ALIAS ALA2(ENTRYPT2),ALA4

• Multiple aliases
  • Multiple alias values can be specified on a single ALIAS control statement as long as they are not in the form alias(entrypoint) Multiple alias values must be separated by commas. For example:

     ALIAS ALIAS1,ALIAS2,ALIAS3,ALIAS4

  • Multiple alias values can span multiple 80-byte records. When this occurs, there must be a nonblank character in column 72 and one of the following must be true:
    • The last alias value on the 80-byte record that is being continued must be followed by a comma and one or more blanks (, …). Here is an example:

               1         2         3         4         5         6         7         8
      ----+----0----+----0----+----0----+----0----+----0----+----0----+----0----+----0
       ALIAS ALIAS1,ALIAS2,                                                  *
         ALIAS3,ALIAS4

    • The last alias value on the 80-byte record that is being continued must be followed by a comma in column 71. For example:

               1         2         3         4         5         6         7         8
      ----+----0----+----0----+----0----+----0----+----0----+----0----+----0----+----0
       ALIAS       ALIAS1,ALIAS2,A_relatively_long_ALIAS_but_not_1023_chars.,*
         ALIAS4,ALIAS5

    • The last alias value on the 80-byte record that is being continued can be coded such that part of the alias value appears on the current 80-byte record and part appears on the next 80-byte record (see the rules for continuation records). Here is an example:

               1         2         3         4         5         6         7         8
      ----+----0----+----0----+----0----+----0----+----0----+----0----+----0----+----0
       ALIAS   ALIAS1,ALIAS2,A_relatively_long_ALIAS.,ALIAS4,Not_too_long_but*
       _wraps.,ALIAS5,ALIAS6

  • If a blank (X'40') follows an alias value, SMP/E assumes there are no more alias values for the current ALIAS control statement.
• Symbolic links
  One format of the ALIAS control statement supported for the binder allows the definition of symbolic links for a load module in a UNIX file system. Symbolic links are defined with the (SYMLINK,symlink) and (SYMPATH,sympath) operands of the ALIAS link-edit control statement.

  Note: To replace or delete the symbolic links specified by an ALIAS control statement, you must first use the ++DELETE MCS to delete the entire load module. You can then redefine the load module with a new set of symbolic links (if any) with inline JCLIN and rebuild the load module by supplying its modules.
  The syntax rules used by SMP/E for (SYMLINK,symlink) and (SYMPATH,sympath) operands on an ALIAS link-edit control statement are the same as those listed in the previous General Considerations and Continuation Records bullets, with the following additions:

  • The SYMLINK and SYMPATH keywords must be in uppercase.
  • Each SYMLINK or SYMPATH keyword must be immediately preceded by an opening parenthesis, followed by a comma and the appropriate value, and terminated by a closing parenthesis.
  • Every SYMLINK must have an associated SYMPATH.
  • The SYMLINK must precede the SYMPATH with which it is to be associated. See the description of the SYMLINK and SYMPATH operands in z/OS SMP/E Reference for a more detailed description of the rules for associating SYMPATH and SYMLINK operands to form symbolic links.
  • A symlink or sympath value may be from 1 to 1023 characters.
  • The rules for enclosing symlink or sympath values in single apostrophes are the same as those for alias values.
  • The rules for including an apostrophe, comma, or right or left parenthesis as part of the symlink or sympath value (not a delimiter) are the same as those for alias values.
  • SMP/E does not enforce any rules the binder may be using as a result of the CASE(MIXED|UPPER) execution parameter.
  The following example shows an ALIAS statement that defines an alias and a symbolic link:

   ALIAS alias_1,(SYMLINK,symbolic_link_1),(SYMPATH,symbolic_path_1)

CHANGE statement

CHANGE statements are saved in the LMOD entry and are associated with the DLIB module name found on the next INCLUDE statement in the JCL. If the same INCLUDE statement is processed later by JCLIN, CHANGE statements in the LMOD entry associated with this INCLUDE statement are deleted and then replaced by any associated CHANGE statements in the latest job. CHANGE statements are passed to the linkage editor only when the associated DLIB module is to be replaced in the load module.

A function SYSMOD must not contain a CHANGE statement in a link-edit step, unless PTFs can be built without an IDENTIFY statement for the changed CSECT.

Note: RESTORE processing is limited for a SYSMOD that uses the CHANGE statement in inline JCLIN. When such a SYSMOD is applied, the existing LMOD entry (if any) is first backed up on the SMPSCDS and is updated with the inline JCLIN containing the CHANGE statement. When that SYSMOD is restored, the backup copy of the LMOD entry (which does not have the updates from the CHANGE statement) replaces the target zone LMOD entry, and the information from the CHANGE statement is lost. Modules whose names were changed by the inline JCLIN remain in the load module under their changed names.

ENTRY statement

Each load module consisting of more than one distribution library module must have an ENTRY statement; otherwise, the entry point of the load module changes each time the load module is relinked by SMP/E.

EXPAND statement

EXPAND statements should not be used in JCLIN data, because they would be saved in the LMOD entry and would cause the load module to be expanded each time it is link-edited. This is not always desirable. However, the EXPAND statement is allowed as input for the ++ZAP MCS. See z/OS SMP/E Reference for more information.

IDENTIFY statement

IDENTIFY statements should not be used in JCLIN data. They are produced as part of servicing a module. If found in the JCLIN, they are stored in the LMOD entry and can result in incorrect data being stored during the application of service.

INCLUDE ddname(name,name…) statement

INCLUDE statements are used to identify the modules in the load module. They are also used to identify utility input to be included when the load module is link-edited. This is denoted by the TYPE comment on the INCLUDE statement. The format of the TYPE comment on the INCLUDE statement is:

INCLUDE ddname(name,name…) TYPE=UTIN

If the TYPE comment is not specified, SMP/E assumes that the INCLUDE statement identifies modules.

• Processing modules

  The INCLUDE statement is used to identify a module to be included in a load module as follows:

  
  

  INCLUDE ddname(name,name,…)

  
  

  where name identifies the module name, and ddname identifies the library ddname where the module resides.

  
  

  A module name must be 1 to 8 uppercase alphabetic (A-Z), numeric (0-9), national (@, #, $), or X'C0' characters. The module is expected to be a member of a data set.

  
  

  The member names are assumed to be modules existing in distribution library ddname. SMP/E builds MOD entries for each member name specified and sets the DISTLIB value in each MOD entry to ddname. (An exception to this is when the ddname is SYSLMOD. In that case, no MOD entry is built for the INCLUDE statement.) SMP/E does not refer to the ddname DD statement to determine the actual library referred to. Therefore, all ddnames specified on INCLUDE statements must be the actual ddnames assigned to the products.

  The INCLUDE statements are not saved in the LMOD entry, because they are not necessary when the load module is link-edited. All link-edits requested by SMP/E are CSECT-replaces; the load module is built from the new version of the updated CSECT and the existing load module from the target library.

  The ddnames SYSPUNCH and SMPOBJ are reserved for inclusions of object decks produced by assembly steps that are not to be link-edited to a distribution library during ACCEPT processing. In both cases, the name stored in the MOD entry's DISTLIB subentry is SYSPUNCH.

• Processing utility input

  The INCLUDE control statement can also be used to identify utility input to be included when link-editing a load module. This utility input may be a definition side deck file containing IMPORT control statements, or any other file to be included during the link-edit. A comment on the control statement indicates to SMP/E the INCLUDE statement identifies a utility input file, not a module.

  
  

  INCLUDE ddname(name,name…) TYPE=UTIN

  
  

  In this case, name identifies the utility input file name and ddname identifies the ddname of the library where the file resides.

  
  

  Each utility input file found on INCLUDE statements is saved in the UTILITY INPUT subentry list of an LMOD entry. The name and ddname determine the uniqueness of a subentry and only one subentry value for a given name and ddname combination is saved in the UTILITY INPUT subentry list.

  
  
  A utility input file can be either a member of a partitioned data set or a file in the UNIX file system. When you identify a member of a partitioned data set, the name must be 1 to 8 uppercase alphabetic (A-Z), numeric (0-9), national (@,#,$), or X'C0' characters. When you identify a file in the UNIX file system,

  • The name can be 1 to 1023 characters in length.
  • The name can be composed of the characters X'41' through X'FE'.
  • The name must be a relative filename. That is, it cannot begin or end with a slash (/).
  • The name can be enclosed in single quotation marks. The name must be enclosed in single quotation marks if it contains a single quotation mark, left parenthesis, right parenthesis, or a comma. The single quotation marks used to enclose the name (the delimiters) do not count as part of the 1023 character limit.
  • Any single quotation mark specified as part of the name (not the delimiters) must be doubled. A pair of single quotation marks count as two characters in the 1023 character limit.
  • The TYPE=UTIN comment cannot extend beyond column 71 (a nonblank character in column 72 indicates statement continuation.)

  For an example, see Example 9: JCLIN for UTIN subentries.

• Continuation records
  • Column 72 of a given 80-byte record must be a nonblank character if the control statement is continued onto the next 80-byte record. The character in column 72 denotes continuation only and is never part of the name value.
  • The data for continuation records (80-byte records, 2 through n of an INCLUDE control statement) can start in column 2 or later and end anywhere up to and including column 71 (for example, if multiple names are being specified). The data for a continuation record must start in column 2 if it is part of a name value that is being continued from the previous 80-byte record. A name value that is continued from one 80-byte record to another 80-byte record must meet these requirements:
    • Extend through column 71 of the first 80-byte record.
    • Have a nonblank continuation character in column 72 of the first 80-byte record.
    • Start in column 2 of the next 80-byte record.
    Here are some examples:
    

    ----+----1----+----2----+----3----+----4----+----5----+----6----+----7--
     INCLUDE SGOSSD(GOSLMOD1,GOSLMOD2,GOSLMOD3,GOSLMOD4,                   x
                        GOSLMOD5,GOSLMOD6)
     INCLUDE SGOSDR('IBM/gos/goslmod3_shipped_as_''element''_MCS_which_spanx
     s_lines_looks_like_this') TYPE=UTIN

    
    
  • If any part of the TYPE=UTIN comment extends past column 71, the entire comment must be moved to the next line and a nonblank character placed in column 72 to indicate that the INCLUDE statement is being continued.
    

    ----+----1----+----2----+----3----+----4----+----5----+----6----+----7--
      INCLUDE SGOSDR(IBM/gos/goslmod1,IBM/gos/goslmod2,GOSLMD7,GOSLMD8)    x
           TYPE=UTIN

INSERT and OVERLAY statements

If a load module is to be linked in overlay structure, you must supply an INSERT control statement for each CSECT in the load module, including INSERT statements for those CSECTs within the root segment. It is not sufficient to properly place the INCLUDE and OVERLAY control statements.

LIBRARY statement

Typically, do not use LIBRARY statements in JCLIN data. An exception is when the CALLLIBS operand is specified on the JCLIN command or ++JCLIN MCS, or when //*CALLLIBS=YES is encountered after a job card preceding a link-edit step. JCLIN processing then allows for the LIBRARY statement to be used to specify those modules (external references) that are to be excluded from the automatic library search during the following processing:

• The current linkage editor job step (restricted no-call function)
• Any subsequent linkage editor job step (never-call function)

A LIBRARY statement should be used only if a SYSLIB DD statement is also used. It should not be used to specify additional automatic call libraries; the SYSLIB DD statement should be used instead.

NAME lmodname(R) statement

When SMP/E encounters either the NAME control statement or the end of input with no NAME statement, SMP/E builds an LMOD entry. How SMP/E determines the name of the LMOD depends on the JCL being scanned:

• If the NAME statement is found, SMP/E gets the LMOD name from the lmodname field of the NAME statement.
• If no NAME statement is found and a SYSLMOD DD statement is present, SMP/E gets the LMOD name from the member name of the data set specified. If no member name is specified, SMP/E issues an error message identifying the JOBNAME and STEPNAME and the reason for the error.
• If no NAME and SYSLMOD DD statements are found, SMP/E searches for the MOD=name operand in the JCL and uses that name as the LMOD name. If no MOD=name operand is found, SMP/E issues an error message.

The NAME statement can also be used to specify a load module's highest acceptable link edit return code value. A comment on the control statement is used to specify the return code value as follows:

  NAME lmodname       RC=rc
  or
  NAME lmodname(R)    RC=rc

The RC=rc comment must be separated from the control statement operands by one or more blanks, and the comment must not extend beyond column 71 (a nonblank character in column 72 indicates statement continuation). Also, no blanks may precede or follow the equal (=) sign.

If, while scanning the link edit control statements for a load module, SMP/E finds the RC=rc comment on the NAME statement, SMP/E saves the specified value in the LMOD entry as the RETURN CODE subentry, creating the subentry if it does not exist or replacing any existing RETURN CODE subentry. If SMP/E finds no RC=rc comment, SMP/E will neither create nor change the RETURN CODE subentry in the LMOD entry.

The RETURN CODE subentry cannot be removed from an LMOD entry using JCLIN. To do this, either the load module must be deleted and then redefined without the subentry, or the subentry must be deleted using UCLIN.

The RC=rc comment on the NAME statement is the only method available to define a RETURN CODE subentry value within JCLIN. Therefore, if you wish to define a RETURN CODE subentry value within JCLIN, you must also define the load module's name using the NAME control statement. Load modules whose names are defined using the member name of the SYSLMOD DD statement, the MOD=name operand of the LINKS procedure specification, or in a COPY step, cannot also define a RETURN CODE subentry value within their JCLIN.

ORDER statement

If a specific order of CSECTs within a load module is necessary, ORDER statements are required to define the load module structure. Simply ordering the INCLUDE statements is not sufficient, because SMP/E does CSECT replacements when relinking the load module and, therefore, changes the order of the CSECTs.

REPLACE statement

REPLACE statements are saved in the LMOD entry and are associated with the DLIB module name found on the next INCLUDE statement in the JCL. If the same INCLUDE statement is processed later by JCLIN, REPLACE statements already in the LMOD entry associated with this INCLUDE statement are deleted and replaced by any associated REPLACE statements in the latest job. REPLACE statements are passed to the linkage editor only when the associated DLIB module is to be replaced in the load module.

SETSSI statement

SETSSI statements should not be used in JCLIN data. They are produced as part of servicing a module. If found in the JCLIN, they are stored in the LMOD entry and can result in incorrect data being stored during the application of service.

SYSDEFSD DD statement

SMP/E uses the SYSDEFSD DD statement to determine the side deck library for a DLL load module. SMP/E determines the ddname for the side deck library by using the lowest-level qualifier of the data set name specified in the SYSDEFSD DD statement. This ddname is saved as the SIDE DECK LIBRARY subentry in the LMOD entry.

The definition side deck for a DLL load module contains IMPORT statements for exported symbols and is saved in the side deck library by the link-edit utility during bind operations. The link-edit utility requires a SYSDEFSD data set during link edit operations whenever symbols are to be exported.

In some cases, you might not need to retain the IMPORT statements and therefore you might not want to save the definition side deck. To meet the requirements of the link-edit utility without saving the definition side deck, define SYSDEFSD as DD DUMMY. You can define a dummy side deck library by specifying the SYSDEFSD DD statement in the JCLIN input stream in any of the following ways:

  //SYSDEFSD DD DSN=SMPDUMMY,DISP=xxx
  -or-
  //SYSDEFSD DD DSN=NULLFILE
  -or-
  //SYSDEFSD DD DUMMY

In each case, the SIDE DECK LIBRARY subentry for the load module will be set to SMPDUMMY. The value SMPDUMMY is treated as a special case by SMP/E and is always allocated as a dummy data set when preparing for link edit operations.

For an example, see Example 8: JCLIN for SIDEDECKLIB subentries.

SYSLIB DD statement

Typically, SYSLIB DD statements should not be used in JCLIN data. However, they can be used for load modules needing to implicitly include modules from other products. Such load modules are commonly used by products that:

• Are written in a high-level language and, as a result, include modules from libraries (such as compiler libraries) that are owned by a different product
• Make use of a callable-services interface provided by another product
• Need to include stub routines or interface modules from different products that may reside in other zones

For such load modules, the SYSLIB DD statement should specify all the automatic call libraries SMP/E is to use when linking the load module. (These libraries should be target libraries.) The low-level qualifier of each data set specified in the SYSLIB concatenation is saved as a CALLLIBS subentry for the associated load module. For SMP/E to link implicitly-included modules from these libraries, the user must provide DDDEF entries for the libraries in the zone containing the LMOD entry.

SYSLIB DD statements are processed only if the CALLLIBS operand is specified on the JCLIN command or ++JCLIN MCS, or if //*CALLLIBS=YES is encountered after a job card preceding a link-edit step. If the CALLLIBS operand or the CALLLIBS comment is not specified, SMP/E ignores any SYSLIB DD statements it encounters.

Including Pathnames in a SYSLIB Concatenation: A DD statement in a SYSLIB concatenation can include the PATH operand to specify a pathname as an automatic call library. A LIBRARYDD comment statement must immediately follow this DD statement and specify the ddname to be associated with that pathname. SMP/E saves the ddname specified on the LIBRARYDD comment statement as part of the CALLLIBS list in the LMOD entry being updated or created. For an example, see Example 7: JCLIN for load modules residing in a UNIX file system.

Note:

1. If a DD statement in the concatenation comes between the DD statement specifying the PATH operand and the LIBRARYDD comment statement, the misplaced DD statement is ignored.
2. If the DD statement specifying the PATH operand is followed by a JCL statement other than a LIBRARYDD comment statement or a continuation DD statement for the SYSLIB concatenation, the LMOD entry is not updated or created. In addition, if the JCLIN was specified in a SYSMOD (instead of being processed by the JCLIN command), processing for that SYSMOD fails.

SYSLMOD DD statement

SMP/E uses either the SYSLMOD DD statement or the NAME statement to determine the target library for the load module, as follows:

• If a SYSLMOD DD statement is present, SMP/E determines the target library ddname by using the lowest-level qualifier of the data set name specified in the SYSLMOD DD statement.
• If no SYSLMOD DD statement is present, SMP/E determines the name by looking at the NAME=dsname option on the procedure statement. The ddname used is the lowest-level qualifier of the data set name specified in the NAME option.
• If no SYSLMOD DD statement or NAME=dsname value is found, SMP/E issues an error message.

The ddname of the target library is saved as the SYSLIB value in the LMOD entry for the load module.

A SYSLMOD DD statement can include the PATH operand to specify a pathname for installing a load module in a UNIX file system. A LIBRARYDD comment statement must immediately follow this DD statement and specify the ddname to be associated with that pathname. SMP/E saves the ddname specified on the LIBRARYDD comment statement as a SYSLIB subentry in the LMOD entry being updated or created. For an example, see Example 7: JCLIN for load modules residing in a UNIX file system.

Note:

1. If the DD statement specifying the PATH operand is followed by a JCL statement other than a LIBRARYDD comment statement, the LMOD entry is not updated or created. In addition, if the JCLIN was specified in a SYSMOD (instead of being processed by the JCLIN command), processing for that SYSMOD fails.
2. An LMOD entry can have at most two SYSLIB subentries. If the LMOD entry already contains two SYSLIB subentries, SMP/E replaces the second SYSLIB ddname with the ddname found on the SYSLMOD DD statement, the NAME=dsname option, or the LIBRARYDD comment statement.

All other statements found in link-edit input

All other link-edit control statements found are saved in the LMOD entry in the order they are encountered, and are passed to the linkage editor whenever SMP/E needs to relink this load module.

SMP/E then scans the link-edit JCL for the link-edit attributes used to link this load module.

These are the link-edit attributes SMP/E recognizes in the PARM field and saves for future processing:

The LMOD entry constructed in this way contains the load module name, the libraries it resides in, the link-edit attributes, and the link-edit control statements required to relink the load module.