Background to repackaging

GDDM V3R2 System Customization and Administration

Background to repackaging

GDDM V3R2 System Customization and Administration
SC33-0871-02

GDDM executable code modules are, by default, loaded dynamically as needed. You can repackage them so that some or all of them are loaded during program initialization. You can also repackage them with a GDDM utility or application program so that everything is loaded together, eliminating dynamic loading entirely.

To understand this, and the similar techniques used to run with different defaults modules, you must understand how dynamic loading takes place.

If you do not do any repackaging, the following series of loads takes place when a GDDM application program or GDDM utility is run:

The GDDM utility or application program is loaded.
The GDDM initially loaded modules are loaded. These are:
1. The application interface controller
2. The external defaults module
3. The subsystem initializer.
Subsequently, other GDDM modules are loaded as needed by the GDDM subsystem initializer, unless they are in shared system storage (saved segment on VM, link pack area (LPA) on MVS, or shared virtual area on VSE).

This process is shown in Figure 46.

Figure 46. The default order of loading during GDDM utilities and programs

You can reduce the number of loads by packaging the items together. You can do this in several ways, the most important of which are:

Repackage the GDDM executable code so that "as needed" modules are loaded with the subsystem initializer
Repackage a utility or application program with all or part of the GDDM executable code
Repackage a utility or application program with a version of the GDDM external defaults module.

These options are shown in Figure 47. Note that any module that you do not repackage is loaded dynamically as needed. GDDM still works regardless of what you put in or leave out of the repackaged modules.

Figure 47. Possible loading combinations

Subtopics:

Notices | Terms of use | Support | Contact z/OS