Using CA extract data sets
The following sections describe how to use CA extract data sets.
Overview
The Recovery utility can create a CA extract data set by reading the input CA data set (which is in sequence by DBD and DSG), identifying the records that are needed for recovery, and writing these records to the CA extract data set, with the following features and benefits:
- Without the CA extract data set, the utility must pass the records directly to a recovery task—which means that only a limited number of tasks at a time can receive the records. When the utility writes the records to the external CA extract data set, many recovery tasks can process CA data at the same time, improving overlap of the tasks. For this processing to occur, you must specify the DIRECT(N) keyword; for more information, see Using-the-DIRECT-keyword.
- After the utility creates the CA extract data set, the utility flags it as complete in the checkpoint data set. If the recovery job is restarted, the incomplete recovery tasks can read the CA extract data set directly; no reprocessing of CA data is required.
- Depending on the recovery situation, you might choose to use a log extract data set but not use a CA extract data set. For example, if you are recovering all members of a CA group, you probably do not want to create the CA extract data set because it would be a copy of the original input CA data set. But you still might want to create the log extract data set so that the utility would not need to reread and resort the log data in case of a failure. For recovery of only a few members of a CA group, you might want to use a CA extract data set.
- The utility does not record the data set names of CA extract data sets in the RECON. If you are using the Automatic Restart feature, the utility records these data set names in the checkpoint data set. The utility writes CA extract data sets in a nonstandard format; they are not compatible with a standard change accumulation data set.
- You can use dynamic allocation models or DD statements in the JCL to allocate CA extract data sets. The dynamic allocation model type for a CA extract data set is XC.
- The utility can write multiple copies of a CA extract data set, but it records only one completed copy in the checkpoint data set. Writing an additional copy can be useful if the first copy experiences a failure (such as an out-of-space condition); if a secondary copy is still valid, the task can continue to write records to it, and recovery tasks that were using it (during the original job step execution, not a restart of the job step) automatically switch from the failed copy to the secondary copy.
Creating CA extract data sets
To create CA extract data sets, perform the following steps:
Define how to allocate the CA extract data set by creating a dynamic allocation model (or by using an existing one) or by defining a DD statement in the job step JCL.You can predefine the dynamic allocation model through the ISPF interface or the Database Administration Console, or you can use the MODEL control statement to define it in the job step. The CA extract data set must be allocated on DASD. Make sure that the model is set up so that unique data set names are created for multiple change accumulation inputs. You can use the &CAGRP substitution keyword in the model data set name to make the name unique for each CA group.
For more information, see Using-dynamic-allocation-models.
Specify the XCUM control statement in the RVPSYSIN control statement data set. Specify the required keywords as follows:
- For the NAME keyword value, specify a name to identify this CA extract data set.
- For the DDN keyword value, specify the name of the dynamic allocation model or the ddname of the DD statement from Step 1.
The XCUM control statement must follow the GLBL control statement and any MODEL control statements (that are named on the XCUM statement) and must precede the ACCUM statement (that names the XCUM statement).
Specify the XCUM keyword on the ACCUM control statement that is used for processing the input CA data set.For the XCUM keyword value, specify the same value as you specified for the NAME keyword on the associated XCUM control statement.
Related topic