Step 2: Identify Application Components

Objective

All of the Components for the Application to be loaded into ISPW must be able to be identified for the Application Load to work.

The Problem

It is probable that the datasets that currently contain the Application components are polluted with:

• Components from other Applications
• Components that are no longer required
• “Junk” Components that should never have been there in the first place.

It is essential that the Load utility is able to identify the Application’s components.

The Solution

There are two ways that this problem can be solved:

• Extract all of the Application (source) components into a new set of libraries.
• Use the Override capability to create a distinct list of all components that the Load utility can drive its processing off.

Each of these solutions is discussed in the subsequent sections.

Extract into New Libraries

This is the easiest way to identify an Application’s components. Prior to the migration, the Application support group would go through the source datasets and copy over all participating components to completely new datasets. The Load utility can be pointed to look at the new datasets and load only those components.

The Load utility is driven from the source components, so it is only necessary to separate out the source components. However, it is probably good practice to separate out the generated parts (LOAD, DBRM, etc.) as well.

Use Override Capability

For organizations with some kind of data dictionary or repository that contains the complete list of components, a file can be created listing them all which can then be used to limit the loading of tasks to those specified in the file. This is described further in Step-3-Exits-and-Special-Customizations.