GDPS HyperSwap

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.

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. You can get fixes from the suppliers of TDMF and FDRPAS to prevent them from trying to move volumes which are defined to GDPS as HyperSwap capable.

If you want to dynamically move these volumes, you need to disable HyperSwap first by setting the GDPS HyperSwap policy option to NO, then suspending mirroring on a pair of devices. This sets the DASD status to NOK, suspends hyperSwap. It also disables Freeze, which is probably not what you wanted. To re-establish Freeze, resynchronise the suspended pair, then run option 5, monitor 2, from the DASD mirroring status panel in RCMF. This will leave HyperSwap disabled.
You re-enable HyperSwap by setting the policy option to HYPERSWAP=YES, suspending and re synching a pair, and running Monitor2 again.

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.

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.

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.

back to top

By entering and using this site, you accept the conditions and limitations of use