Default processing options overrides

This option invokes the Catalog Manager Drop Recovery option when Db2 objects are dropped in an alter-type work ID. JCL Generation inserts the CATRECOVER keyword into the AEXIN input stream. This option causes Execution to invoke Catalog Manager to log the dropped objects. Catalog Manager can rebuild the objects. To use this option, you must have Catalog Manager installed.

Allows you to generate JCL for only phase 1 of a migration. For Batch Execution JCL Generation, selecting this option inserts the SENDONLY YES keyword into the AJXIN. The data sets that are required by the utilities in phase 2 are not included in this JCL.

Determining How to Execute a Worklist

A migrate-type worklist for migrating within the same subsystem might contain only one phase, in which all of the worklist commands are executed as one job. A migrate-type worklist for migrating to another subsystem, however, would contain two phases, each identified by the -MIGR worklist command. A typical migrate-type worklist that includes both DDL and data has unloads in phase 1, followed by DDL, loads, and other utilities in phase 2. A -STOP worklist command separates the two sections. Phase 1 is executed on the sending subsystem, and phase 2 is executed on the receiving subsystem.

By default, JCL is generated initially for a migrate-type work ID to execute both phase 1 and phase 2. If you want to generate the JCL for only phase 1, you can select the Generate JCL for the send phase only option on the Execution Override Options panel. Selecting this option prevents the deletion of data sets when the work data sets are put on temporary work packs, or prevents the unnecessary usage of space if the receive-type worklist and JCL are not executed immediately.

When you migrate data, data structures and data, or data structures only to a different subsystem, you must use a receive-type work ID on the receiving subsystem to execute phase 2 of the worklist. Phase 2 of the worklist creates the data structures and loads any migrated data. Receive-type work IDs cause Execution to begin processing with phase 2 of the worklist. Execution reads the worklist and searches for the -MIGR PHASE-2 command. If Execution does not find the command, it processes the worklist from the beginning.

When the worklist is executed in two phases, you must also create a receive-type work ID on the receiving subsystem to build the new data structures and load any migrated data. The receive-type work ID cannot contain any migrate or change requests. It is only used to track the execution process and to restart the worklist if any errors occur. In addition, if the receiving subsystem does not have access to the data sets on the sending subsystem, or if the two subsystems do not share the same DASD, you must transfer the worklist and all of the SYSRnnnn data sets (unloaded flat files) to the receiving subsystem.