Withdrawing DFSMShsm background copies

A FlashCopy® relationship between a source volume and a target volume that was established through a FRBACKUP command should never be withdrawn outside of DFSMShsm control. Doing so will invalidate the backup version, but DFSMShsm will still manage the version as if it was valid. This may result in a data integrity exposure.

When it is necessary to withdraw one or more relationships established by a FRBACKUP command, you can use the following command:

FRBACKUP COPYPOOL(cpname) WITHDRAW

This command withdraws all current FlashCopy relationships associated with the volumes in the most recent VALID version for the specified copy pool. The version of the backup is marked as invalid unless it has a dump associated with it. In that case it becomes a dump only version.

If a dump is in progress for the version, then all incomplete dump copies for that version are marked as partial and are to be resumed. Any dumps completed before submission of the WITHDRAW command are kept and marked successful. Any volume that is currently being dumped when the WITHDRAW command is submitted is marked as a failure, though the dump is allowed to finish. Volumes that have yet to begin dumping at the time the command is submitted are marked as failed.

When a copy pool incremental version is withdrawn, the persistent relationships are withdrawn and the version is marked failed if the background copy was in progress. If the background copy is completed, the version remains VALID and recoverable.

If the most recent valid version is not generation zero and any relationships are withdrawn, then the withdrawn version is also deleted because it is no longer usable.

The withdraw can only be performed at the copy pool level. If any part of a copy pool backup version is invalidated, then the entire version is invalidated.

Attention: Use the LIST COPYPOOL command or the ARCXTRCT macro to ensure that you do not withdraw the only valid fast replication backup version. Withdrawing the only valid fast replication backup version will prevent recovery from being performed.

Note:

If a volume pair is withdrawn before DFSMShsm completes the copy of the tracks that the target VTOC resides on, the target volume might become inaccessible. To avoid this, DFSMShsm checks during WITHDRAW processing if a FlashCopy relationship exists on tracks where the VTOC resides, and invokes ICKDSF to initialize the volume. FlashCopy relationships on FlashCopy version 2 enabled volumes are withdrawn and the VTOC is recreated.
When a volume is initialized in a sysplex, only the host on which the volume was initialized is aware of the changes to the VTOC. You should vary off, and then on, the volumes identified in message ARC1838I to allow all hosts that share those volumes to recognize the changes to the VTOC. Message ARC1838I is most often issued when a volume is initialized in a sysplex using a copy pool defined with zero versions (NOCOPY mode).