Considerations for the FRBACKUP COPYPOOL command

The following topics are related to your use of the FRBACKUP COPYPOOL command:
  • Processing a FRBACKUP COPYPOOL command: During the processing of a FRBACKUP COPYPOOL command, the new backup version is directed to the target volumes that contain the oldest backup version (after the requested number of versions has been reached). If a FRBACKUP COPYPOOL command fails, there are only n-1 valid versions available, where n is the number of requested versions. When a failed version exists, the failed version is the target of the new copy until that copy is successful. The backup version is not incremented for subsequent backups until a successful version has been created.
  • When FlashCopy® is the fast replication technique being used: DFSMShsm returns control to the system after a FlashCopy relationship for each volume has been established. However, the background copies for those volumes last from minutes to hours longer, depending on criteria such as:
    • The number of background copies being processed.
    • The amount of other higher priority activity that exists in the storage subsystem.
    Notes:
    1. When you are using FlashCopy version 1, any subsequent FRBACKUP COPYPOOL command that is issued against the same copy pool or against another copy pool with a common storage group before all the background copies are complete causes the command to fail. This restriction does not exist for FlashCopy version 2 because a source volume can be in multiple concurrent relationships.
    2. If catalog information is saved at the time of backup, you must have sufficient space available on your ML1 volumes to accommodate catalog information data sets. For more information on saving catalog information at time of backup, see Saving catalog information at the time of backup.
    3. Some of the FlashCopy options are incompatible. For example, preserve mirror operation cannot be used in combination with space efficient FlashCopy or fast reverse restore. Consider these restrictions when you define a copy pool.
  • Using the TSO command: When you use commands that specify WAIT or NOWAIT, the results that are sent back to the user depend on whether the WAIT parameter is specified, and the success or failure of one or more volumes:
    • If WAIT is specified and all volumes process successfully, a return code of zero is returned.
    • If WAIT is specified and one or more volumes fail, a nonzero return code and associated messages are returned.
    • If WAIT is not specified, control is returned to the user after the command has been accepted and verified. All messages continue to be issued, but you are not notified when the command completes.
  • Using the TOKEN parameter: The TOKEN parameter accepts a token of up to 40 bytes in length that is associated with that particular version of the copy pool. The token is used to reference a particular backup version. Tip: Use unique tokens for each version so that you can easily reference the correct version.

    The token is returned as part of the LIST and ARCXTRCT data for a copy pool.

  • Refreshing the UCB on remote systems: The VTOC and the volume serial on the target volume may have changed as a result of this operation. Before the volume can be accessed on any remote system, the UCB must be refreshed. The refresh occurs automatically if the volume is online and the device manager REFUCB function is enabled. You enable the REFUCB function through PARMLIB member DEVSUPxx or the MODIFY DEVMAN command. For more information, refer to the description of the REFUCB keyword in z/OS MVS Initialization and Tuning Reference or z/OS MVS System Commands.
Parent topic: Creating a fast replication backup