Server Guide

Step 2: Building the CICS load module

The packaging step generates a packaged image file. Upload this packaged image as binary to OS/390 and place it in your OS/390 image library (RECFM=FB, LRECL=80).

Edit ABT.V4R5M0.SABTJLIB(ABTCBLD) to build an executable CICS/ESA load module from the packaged image file. In ABTCBLD, find the correct PROC from the list below:

ABTCMF1B
Builds a "load from file" load module for a CICS single image. ABTCMF1B creates a load module that points to a packaged image, so that the load module needs to be built only once for each new application image. See *** for more information.

ABTCMF2B
Builds a "load from file" load module for a CICS dependent image. ABTCMF2B creates a load module that points to a packaged image, so that the load module needs to be built only once for each new application image. See *** for more information.

ABTCMN1B
Builds a statically linked load module for a CICS single image.

ABTCMN2B
Builds a statically linked load module for a CICS dependent image. When using this procedure, you must first run the ABTCVM2B procedure for the base image. ABTCMN2B executes the base image created by ABTCVM2B.

ABTCVM2B
Builds a load module for a CICS base image.

Remove the comments from all the parameters for the specified proc and provide the information requested. Note that the following parameters are not required for all the procedures.

Submit the JCL. The module produced is not different from any other C or COBOL CICS load module. If you receive an error while building the load module, see Appendix A, Messages and codes for more information.

Building a load module using the ABTCMF1B or ABTCMF2B procedure

Run the ABTCMF1B or ABTCMF2B procedure against each new application image only once. Once a load module is created for an application image, you can skip this step.

Use the ABTCMF1B or ABTCMF2B procedure during development to test your applications quickly, without needing to run JCL to build a load module from the packaged image. For a production library, however, use the other procedures, which incorporate the entire image into the load module, for better performance.

WARNING: When storage protection is active on a CICS region (SIT STGPROT=YES) and you intend to use these procedures, the CICS program definition (PPT) for your application program must specify EXECKEY=CICS. Because the ABTCMF1B and ABTCMF2B procedures are not considered appropriate for applications in production use, we recommend that you fully test your application with the ABTCMN1B or ABTCMN2B procedure with an EXECKEY=USER prior to implementing an application in production mode.

Like the other procedures that build a load module from a packaged image, ABTCMF1B and ABTCMF2B produce a load module in your load module library. Unlike the other procedures, the load module created by ABTCMF1B or ABTCMF2B contains only a pointer to the packaged image in an image library. This pointer allows you to repackage the application image without the need to build a load module from it. This is called a "load from file" load module.

The load module created will always have the same name as the packaged image and will always point to that image in the image library. The application image can be repackaged from the workstation and uploaded to OS/390, then run without having to rebuild a load module. In this way, the ABTCMF1B and ABTCMF2B procedures resemble the ABTVBLD program used to produce a DLL for CICS on the workstation.

Your packaged image must reside in an image library defined by your system programmer. See Obtaining information about a CICS load module to determine the characteristics of the image library set up by the system programmer.

You can use the ABTCMF1B procedure to build load modules of single images; ABTCMF2B builds load modules of dependent images. Load modules of base images cannot be built for this type of processing.

Consider the following example:

  1. A programmer packages and uploads a single image called MYSAMPLE.
  2. The programmer uses the procedure ABTCMN1B to build a load module for the packaged image MYSAMPLE.
  3. The programmer can then define, install, and test MYSAMPLE.
  4. The programmer returns to the workstation and makes changes to MYSAMPLE, based on testing.
  5. The programmer repackages the application and uploads it to OS/390 as a packaged image again. The load module MYSAMPLE contains the old application.
  6. The programmer must run the JCL to rebuild the load module for MYSAMPLE.
  7. The programmer can now test MYSAMPLE again.

Now, consider this example:

  1. A programmer packages and uploads a single image called MYSAMPLE.
  2. The programmer uses the procedure ABTCMF1B to build a load module for the packaged image MYSAMPLE. The load module created by this job step points to the packaged image.
  3. The programmer can then define, install, and test MYSAMPLE.
  4. The programmer returns to the workstation and makes changes to MYSAMPLE, based on testing.
  5. The programmer repackages the application and uploads it to OS/390 as a packaged image again. The load module is still pointing to MYSAMPLE, but MYSAMPLE is now the new application.
  6. The programmer can test MYSAMPLE again without rebuilding the load module.

Using these procedures for each new packaged application image allows you to forego the build step when you repackage the same application.


[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]