Server Guide

Building a load module using the ABTIMF1B or ABTIMF2B procedure

Tip icon
Run the ABTIMF1B or ABTIMF2B procedure against each new application image only once. Once a load module is created for an application image, you can skip this step. There is a restriction in this mode of operation for IMS application images. It cannot be used in the scenario where the Smalltalk program is called from another program or in a CPI-C program that is running under IMS.

Further, use the ABTIMF1B or ABTIMF2B 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.

Like the other procedures that build a load module from a packaged image, ABTIMF1B and ABTIMF2B produce a load module in your load module library. Unlike the other procedures, the load module created by ABTIMF1B or ABTIMF2B 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.

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

You can use the ABTIMF1B procedure to build load modules of single images; ABTIMF2B 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 ABTIMN1B to build a load module from the packaged image MYSAMPLE.
  3. The programmer tests 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 ABTIMF1B 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 tests 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.

Note:If you use either ABTIMF1B or ABTIMF2B to create a load module with a fetchable image, you must rename the image to the calling module name.


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