- IBM Metro Mirror
- PPRC Commands
- EMC SRDF mirroring
- SRDF Commands
- HDS Universal Replicator
- Global Mirror
- z/OS Global Mirror
Do you want to learn why Database backups are different from file backups? Click HERE to find out.
Do you want to learn why
are different from file backups?
Click HERE to find out.
A Peer-to-Peer Virtual Tape Server (PtPVTS) consists of two separate Virtual Tape Servers (VTSs) which can be located at the same site or two remote sites. The PtPVTS appears to the host z/OS system as a single automated tape library. GDPS can manage one or more PtPVTSs, or 'composite libraries' as they are sometimes called. At present, the only tape library supported by GDPS is the IBM VTS.
The Virtual Tape Mirroring section describes the available virtual tape mirroring options. GDPS requires that PtPVTS systems run in Immediate Copy Mode, with the tape rewind command held until data is stored in both VTS buffers. GDPS requires that all the primary data, both disk and tape, is held in the same site, and mirrored to disk and tape in the secondary site. It ensures this is correct at initialization and configuration processing time. All tape mount requests are directed to the Primary VTS, so if the Primary VTS is unavailable, the mount request will fail.
The GEOPARM section explains how a PtPVTS is defined to GDPS. PtPVTS and VTS names can only have up to 8 characters, and its important that the VTS names are specified in the correct order, as this is the only way that GDPS knows which library is in the primary site, and which is in the secondary. The parameter order is
The z/OS dialogs which dictate the GDPS policy options contain a GEOPLEX OPTIONS page. One of these options determines whether or not a problem within a virtual tape system can initiate a full freeze, including freezing all the disks. The policy statement is
The default is YES. You need to consider how important it is that your tape data is exactly in step with your disk data, how likely it is that errors within the PtPVTS systems will cause unwanted freezes, and the impact of those unwanted freezes, before you decide to leave this parameter at the default value. Also if you are using GDPS HyperSwap, then you cannot use TAPEINIATEDFREEZE=YES, you must change it to TAPEINITIATEDFREEZE=NO.
Tape freeze means that GDPS will suspend dual copy operations to every secondary VTS in the freeze group. Tape files which were written successfully to the primary VTS before the freeze, and are in the process of being copied to the secondary will still proceed. This is a 'Freeze and Go' operation, the Primary VTS will continue accepting tape mounts, if it is able, and the PtPVTS system will enter 'change recording mode'. It will queue any virtual volumes requiring a dual copy until mirroring operations are resumed. While the PtPVTS is frozen, systems will receive the tape rewind/unload command from the primary VTS. GDPS records the tape VOLSERs for mounted tape volumes at freeze time, and can display them later.
Non-VTS tape systems, VTSs not defined to GDPS, and VTSs not in the freeze group (e.g. with 'N' specified in the Geoparm), are not affected by freeze operations.
The tape freeze function is invoked by a DASD freeze event, and also by a tape freeze event if TAPEINITIATEDFREEZE is set to YES. A tape freeze event is generated by messages CBR3785E and CBR3787E.
Freeze will not be invoked if it is not enabled. To enable freeze, all disk and tape volumes must be in full duplex status, the primary disk subsystems and Primary VTSs must be in the same site, and GDPS Monitor2 processing must have placed the GDPS system in Green 'OK' status. If any PtPVTS in the freeze group is not running in Primary and Immediate copy mode, Freeze cannot be enabled. You need to use the RCMF 'I' Initialise line mode command to restore the PtPVTS to its correct status.
If there is no disaster in progress, the PtPVTS subsystems can be resynchronized using the panel commands, or the TAPE='START SECONDARY' script.
It there is a disaster, the operator will get a takeover prompt which executes a script to failover the workload to the surviving site: the script command TAPE='SWITCH' will switch the primary copy of data to the alternate site.