Server Guide
-
- 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 MVS,
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:
- A programmer packages and uploads a single image called MYSAMPLE.
- The programmer uses the procedure ABTIMN1B to build a load module from the
packaged image MYSAMPLE.
- The programmer tests MYSAMPLE.
- The programmer returns to the workstation and makes changes to MYSAMPLE,
based on testing.
- The programmer repackages the application and uploads it to MVS as a
packaged image again. The load module MYSAMPLE contains the old
application.
- The programmer must run the JCL to rebuild the load module for
MYSAMPLE.
- The programmer can now test MYSAMPLE again.
Now, consider this example:
- A programmer packages and uploads a single image called MYSAMPLE.
- 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.
- The programmer tests MYSAMPLE.
- The programmer returns to the workstation and makes changes to MYSAMPLE,
based on testing.
- The programmer repackages the application and uploads it to MVS as a
packaged image again. The load module is still pointing to MYSAMPLE,
but MYSAMPLE is now the new application.
- 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 ]