Previous Topic: Dynamically Link OptionsNext Topic: Identify External Action Block Libraries

External Action Blocks › Create External Action Blocks in HE › Compile and Link-edit External Action Block

Compile and Link-edit External Action Block

You are responsible for compiling and link-editing the External Action Block. The EAB can be statically linked, included in another module, or dynamically linked, its own module.

A static EAB can be called from a Compatibility module, from a static module or a dynamic DLL. When linking a static EAB, do not link DL/I, COBOL, DB2, CICS, or ISPF system modules into the load module for the External Action Block. The installation process links these modules into your final executable load module.

  1. When the static EAB is called from a Compatibility module and the statically linked EAB is built, use the following compile and link options:
    1. Compile the EAB with the options OPT, NOSEQ, NODLL, NODYNAM, RENT, and NOEXPORTALL
    2. Link edit the EAB with the options RENT, REUS, NCAL, and DYNAM(NO).
    3. The NCAL linked EAB must be placed in a library in the External Compatibility Libraries panel.
  2. When the static EAB is called from a static module or a dynamic DLL, the statically linked EAB must be built using the following compile and link options:
    1. Compile the EAB with the options OPT, NOSEQ, DLL, NODYNAM, RENT, and NOEXPORTALL
    2. Link edit the EAB with the options RENT, REUS, NCAL, and DYNAM(NO).
    3. The NCAL linked EAB must be placed in a library in the External Action Block Load Libraries panel.

When the EAB has been packaged with the Dynamically Link option of Yes, the EAB must be built as a DLL to be invoked by a generated application. Modules that are called by an EAB built as a DLL must also be a DLL. DLLs require that modules be bound as objects in Program Management Format 3 (PM3) and must reside in a PDSE library.

To build the EAB as a DLL, use the following compile and link-edit options:

Follow these steps:

  1. Compile the EAB with the options OPT, NOSEQ, DLL, and EXPORTALL in addition to the default compiler options.

    Note: Selecting DLL forces the RENT and NODYNAM compiler options to also be used.

  2. Link the EAB with the options RENT, REUS, and DYNAM(DLL).

    Note: Do not confuse the compiler option NODYNAM with the link-edit option DYNAM(DLL). The two are not the same as one is a compiler option while the other is link option.

  3. Copy the EAB DLL to a data set that allow the DLL to be resolved in the target environment. For TSO and IMS this is a data set that is part of the STEPLIB concatenation. For CICS this is a data set that is part of the DFHRPL concatenation. Also, if the target environment is CICS, a CICS program definition must be added for the resulting EAB DLL.

Note: For information about DLLs, see IBM's Language Environment and the Program Management (Binder) documentation.

When the EAB has an associated Dynamically Link Packaging property set to Compatibility, the EAB must be built as a non-DLL. Modules that are marked for Compatibility must follow standard OS or LE linkage conventions and must operate in the same AMODE as the caller. These modules are not DLLs and must be fully resolved programs, eligible for being the target of an OS style dynamic program call.

To build the EAB as a non-DLL, use the following compile and link-edit options:

  1. Compile the EAB with the options OPT, NOSEQ, NODLL, RENT in addition to the default compiler options.
  2. Link edit the EAB with the options RENT, REUS.
  3. Copy the non-DLL EAB to a data set that will allow the DLL to be resolved in the target environment. For TSO and IMS, this is a data set that is part of the STEPLIB concatenation. For CICS this is a data set that is part of the DFHRPL concatenation. Also, if the target environment is CICS, a CICS program definition must be added for the resulting non-DLL EAB.