The SMS copy pool construct contains the names of up to 256 storage groups that can be processed collectively for fast replication operations.
When you define a copy pool through ISMF, the individual source pool storage group names are recorded. The actual volumes that are associated with each storage group are retrieved during subsequent processing. Consequently, the volumes that are processed during a function, such as backup, might not be the same volumes that are associated with the storage group at the time that the copy pool was established.
Example: If one or more volumes are added to a storage group within a copy pool, those volumes are automatically processed as part of the next backup. You are not required to update the copy pool definition unless you want to add or remove storage groups from the pool.
You can maintain as many as 85 backup versions for each copy pool. Each version can have a DASD copy, a dump tape copy, or both. The number of backup versions kept on DASD is specified on the SMS copy pool definition panel. Each DASD maintained copy requires a unique target volume for each source volume. If you specify five dedicated versions, there must be five target volumes that are available for each source volume that is associated with the copy pool. All target volumes must be available when you issue the FRBACKUP COPYPOOL(cpname) PREPARE command. If the PREPARE function is not performed, the target volumes need not be available until the actual backup version is created. The number of tape versions that are maintained depends on the expiration settings of the dump classes used to create the individual tape copies.
In the COPY POOL DEFINE and COPY POOL ALTER panels, you can use the Number of DASD Fast Replication Backup Versions with Background Copy, FRBACKUP to PPRC primary Volumes allowed, FRRECOV to PPRC primary Volumes allowed, Capture Catalog Information for Data Set Recovery, Allow Fast Reverse Restore, and other fields to tailor your copy pool definition.
You can use the Number of DASD Fast Replication Backup Versions with Background Copy field to specify the desired number of DASD fast replication backup versions with background copy between 0 and 85. A value of 0 causes DFSMShsm to use NOCOPY mode when creating the DASD backup copy. When the copy pool is defined with fast reverse restore capability, a DASD backup copy created in NOCOPY mode can be used for recovery and as a backup copy from which to create a dump tape copy. The DASD backup copy is kept until it is withdrawn or deleted. When the copy pool is defined without fast reverse restore capability, it is only used to create a point-in-time backup copy from which a dump tape copy is created. Once the tape copy is successfully created, the DASD backup copy is deleted. Values between 1 and 85 cause DFSMShsm to use COPY mode. A COPY mode environment allows recovery of the latest versions from DASD or dump tapes. For example, a COPY mode environment with 2 versions specified and all versions dumped, the latest two versions are on DASD and tape, while the older versions (up to 83) are only available as dump tape copies. When a new DASD version is created, it replaces an existing DASD version. Specifying two copies guarantees that one backup copy is always available on DASD.
You can specify whether DFSMShsm uses FlashCopy consistency groups to create consistent copy pool backup copies in the FlashCopy Consistency Group field. If you specify Y (yes), the FlashCopy consistency group option will be used and consistent copes are required. If you specify N (no) or leave the field as blank, the FlashCopy consistency group option will not be used.
You can specify whether DFSMShsm uses FlashCopy consistency group to create consistent copy pool backup copies in the FlashCopy Consistency Group field. If you specify Y (yes), FlashCopy consistency group option will be used and consistent copies are required. If you specify N (no) or leave the field as blank, FlashCopy consistency group will not be used.
You can specify whether catalog information for all catalogs should be collected at time of backup by changing the value in the Capture Catalog Information for Data Set Recovery field. If you enter R (required), the fast replication backup request fails if the catalog specified in the copy pool definition cannot be found or if the catalog information cannot be retrieved and captured in its entirety. If you enter P (preferred), under the same conditions, the backup copy pool version is valid, but you might not be able to recover some data sets in the version. Entering N (no) disables the recovery of moved or deleted data sets, this is the default.
Because mature or highly utilized catalogs often contain logical errors, capturing catalog information from a catalog with errors fails and causes the catalog search interface to return an error. When the catalog search interface returns an error, message ARC1812I is issued.
When required is specified, all catalog errors must be corrected to allow fast replication backup to succeed. Alternatively, if preferred is specified, capturing the catalog information will fail, but the fast replication backup request will continue processing.
You can also specify whether fast reverse restore is allowed by changing the value in the Allow Fast Reverse Restore field. If you enter Y (yes), recovery of a FlashCopy source from the FlashCopy target can occur without waiting for the background copy to complete. Entering N (no) disables fast revere restore and requires you to wait for the original FlashCopy operation to complete prior to starting recovery, this is the default. The copy pool fast reverse restore setting is saved at the time of the fast replication backup. During fast replication recovery, the use of fast reverse restore is based on the DASD backup version setting and the state of the current FlashCopy relationships.
The other fields on the COPY POOL DEFINE and COPY POOL ALTER panels allow you to further tailor your copy pool definition.