Repostor Backups

Do you want to learn why Database backups are different from file backups? Click HERE to find out.

Do you want to learn why
Database backups
are different from file backups?
Click HERE to find out.

GDPS HyperSwap

HyperSwap will automatically switch disk processing between sites and can run as part of the full GDPS offering, or as 'GDPS/PPRC HyperSwap Manager'. This is is cut down version of GDPS which includes the ability to transparently switch from primary to secondary disk subsystems, ensuring data consistency at the secondard. As there is no scripting facility or production SYSPLEX management, recovery takes longer than with the full version, so the RTO is longer.

Raw GDPS protects from site disasters by switching all data and processing to a second site. This is a disruptive process as it requires an IPL on all systems. GDPS HyperSwap simply switches all disk processing from the primary site to the secondary site, while leaving the CEC processing intact. This is a transparent process, and can be a planned event for disk maintenance, or an unplanned event in response to problems. It is controlled by GDPS scripts and does not require IPLs.
If your system can dynamically swap primary DASD locations, then to sustain performance, you need the same connectivity from your primary processors to your secondary DASD, as you have to your primary DASD.

If you run HyperSwap, you must PPRC mirror all your volumes, except the GDPS utility volumes and Sysplex CDS files. All volumes must be under GDPS control, and they must all be in the freeze group, with the freeze indicator set to 'Y' for every SSID in the GDPS Geoparm.

Some Hyperswap restrictions

HyperSwap introduces a few restrictions to some other disk work. TDMF and FDRPAS both move volumes around non disruptively by switching UCB pointers. HyperSwap works at UCB level, so if you start dynamically switching UCBs, HyperSwap will act on incorrect volumes. Managing Hyperswap with TDMF used to be a manual process, but both products now disable hyperswap briefly while they swap the UCBs over.

DFSMS Concurrent Copy function cannot work with HyperSwap, because Concurrent Copy holds un-copied data that has changed in a portion of the disk subsystem cache. This data is not mirrored. If you perform a HyperSwap while a Concurrent Copy operation is in progress, the copy will probably fail, and if it does not, it will certainly produce an invalid backup. If you do a planned move with HyperSwap, do it when no concurrent copies are running. If you run concurrent copy alongside unplanned HyperSwap, be aware that this will cause problems as active concurrent copy jobs will abend when a switch starts and need to be restarted once the switch is complete.

SYNCSORT can also have problems with Hyperswap as it sometimes uses Cache Fast Write (CFW) for its sortwk datasets. Of course CFW data is not PPRCed so any active data in CFW will be lost if HYPERSWAP SUSPEND is issued. This has caused problems for BMC unloads, which then failed with an S130 abend. It is best to disable CFW, but in anycase, if PPRC is active and CFW is enabled, then the DS8000 storage subsystem will convert CFW to DFW.

If you are running PtPVTS systems under GDPS, then you cannot specify TAPEINITIATEDFREEZE=YES, if you are using HyperSwap. The default value for this parameter is 'YES', you must change it to 'NO'.

HyperSwap does not work with P/DAS, and it appears not to work with CA-MIM too.

If you are running with 3 site PPRC environment using the CASCADE option, then the HYPERSWAP RESYNCH command will not work. You need to use HYPERSWAP SUSPEND then START SECONDARY to get the same result. If you have any GDPS scripts that use the SWITCH HYPERSWAP RESYNCH command then they will fail with a syntax error, even though the syntax is correct.

back to top

Remote Data Mirroring

Lascon latest major updates