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:
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.
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.
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.