When a clone pair consists of a source unit and a clone unit, no special aspects need be borne in mind. This is not the case when a clone pair consists of a target unit and a clone unit. In this case the clone pair generally cannot be accessed via the VSN or the pubset ID because the target unit is not readable. If the source unit is attached, the pubset ID of the source unit can be specified in the clone session commands using the UNIT=*BY-PUBSET(...) operand in conjunction with SELECT=*TARGET-UNIT.
The following requirements must be met to permit a clone pair with a target unit to be selected via the VSN or pubset ID:
The source unit is attached.
In addition, either remote copy mode must be interrupted with
/ACTIVATE-CLONE(/SHOW-REMOTE-COPY-STATUSindicates the remote copy statusIN-HOLDorERROR) or synchronous processing mode must be set and the remote copy pair must be synchronized when remote copy mode is active.
SF pubsets can be renamed implicitly using /ACTIVATE-CLONE NEW-PUBSET=<new cat id> provided the server has connections to the remote storage system (i.e. this can be reached directly from the server). The I/Os on the source unit can be suspended during ongoing operation using /ACTIVATE-CLONE and the HOLD-IO=*UNTIL-ACTIVATED operand to permit consistent splitting.
Scenarios for TimeFinder/Clone in SRDF configurations
Without renaming of the clone units
The source unit and target unit form a remote copy pair (see the figure below).
At the same time the two also form a clone pair:
The source unit with the clone unit of the local storage system
The target unit with the clone unit of the remote storage system
Figure 31: TimeFinder/Clone with SRDF, no renaming of the clone units
The server has no connections to the remote storage system, which cannot therefore be accessed directly from the server. The target unit cannot be addressed via the VSN or pubset ID. The source unit has pubset ID A.
The clone pair in the remote storage system is activated using /ACTIVATE-CLONE UNIT=*BY-PUBSET(PUBSET=A),SELECT=*TARGET-UNIT. In the case of concurrent target units, the required target unit is selected by specifying the RA group.
With renaming of the clone units
The source unit and target unit form a remote copy pair (see the figure below).
At the same time the two also form a clone pair:
The source unit with the clone unit of the local storage system
The target unit with the clone unit of the remote storage system
Figure 32: TimeFinder/Clone with SRDF with renaming of the clone unit in the remote storage system
The server has connections to the remote storage system, which means that the latter can be accessed directly by the server. The target unit cannot be addressed via the VSN or pubset ID. The source unit has pubset ID A.
/ACTIVATE-CLONE UNIT=*BY-PUBSET(PUBSET=A,NEW-PUBSET=B) causes the clone pair in the local storage system to be split and the clone unit’s pubset ID to be changed to B.
/ACTIVATE-CLONE UNIT=*BY-PUBSET(PUBSET=A,NEW-PUBSET=C),SELECT=*TARGET-UNIT is used to split the clone pair in the remote storage system, and the pubset ID of the clone unit is changed to C. In the case of concurrent target units, the required target unit is selected by specifying the RA group.
This permits the units to be used as follows, for example:
the source unit (with pubset ID A) for the main application
The clone unit of the local storage system (with pubset ID B) for the backup
the target unit as a copy in case a disaster occurs
The clone unit of the remote storage system (with pubset ID C) for evaluations
/RESTORE-FROM-CLONE for an SRDF target unit can be used only if the target unit is in the READY status, i.e. the remote copy status is IN-HOLD or ERROR and TARGET-ACCESS has the value *DIRECT. As a result of this, the last consistent status can, for example, be copied from the clone unit to the target unit in the event of a disaster.
The data can therefore be copied from the clone unit on the remote storage system to the source unit on the local storage system in several stages.