Setups for Different Types of Moves › CA-Panvalet Moves › Member-existence Exit: APAS0222 › GDG Considerations

GDG Considerations

Limitations with the standard move style JCL:

When members are being deleted to protection files, these protection files are maintained as GDG data sets. This processing requires special attention because the actual data set name corresponding to relative generations is not adjusted immediately when new generations are created, but is deferred until the end of the job. If the same GDG index is used in two different delete steps of a job, you encounter JCL errors.

This situation can occur in two different ways.

• If you have two different Library Codes that access the same sets of CA‑Panvalet libraries that are both used in the same move cycles. The first Library Code is processed correctly. The second runs into problems in its steps to delete members to protection files.
• If you are moving members rather than copying them from some level higher than the starting level, you can encounter problems if you are performing moves both to and from that level in the same move cycle. For example, you are using the default levels of Test, QA, and Prod. You have a Library Code that used a protection file for the QA CA‑Panvalet library, and when moving from QA to Prod you Move the members rather than Copy them. In a Move Cycle, you have QA to Prod moves involving this Library Code for one Move Request, and Test to QA moves for another Move Request. During the QA to Prod move, the QA members are deleted to the GDG QA protection file. At the beginning of the Test to QA move you run into problems if it is necessary to delete members from the QA library before moving the members from Test to QA.

If you encounter these problems, just use the normal restart procedures to get through the current move cycle. Because you are restarting as a new job, the correct data sets are used. After the move completes, you can take one of three actions to prevent this from happening in the future:

1. Quit using protection files.
2. Change to use the REXX style of Move JCL. It uses APTALLOC instead of JCL to allocate the GDG data sets. APTALLOC uses a feature of dynamic allocation that commits new GDG versions when the data sets are closed, instead of at the end of the job.
3. Change the CA‑Panvalet model to generate a new job at the end of the move JCL, and to submit that job.

Other GDG problems:

If you have not created any previous CA‑Panvalet protection files, you receive a JCL error when running the standard style of move JCL, or an APTALLOC error for the REXX style of move JCL the first time you perform a move using that protection file. To remedy this, create the first generation manually.