GDPS Scripts

While RCMF lets you manage banks of disks with a single action command, its useful if you can string all the commands needed for a single scenario together and execute them as one. GDPS does this by scripts. You manage these by using option 6, 'planned actions' from the front GDPS panel. A typical script to freeze the data, take a flashcopy from the remote disks, then resynchronise the data is below. You might use this to do a Disaster Recovery test from the FlashCopy disks, while still preserving mirroring on the Secondarys. Another advantage of GDPS scripts is that it can process each disk array in parallel, while RCMF does everything serially. That makes GDPS scripts faster than RCMF.
If you write a script, then you are also planning out your work, and it can be peer reviewed then tested before it is used in action. Once a script is proven, it can be used many times with confidence that you will get the same result each time.
A sample script is:


If you don't specify the NOFLASH, then the GDPS will do its own FlashCopy, which it withdraws once the Secondarys are established.

There are several script commands. Some of the DASD and TAPE commands are covered in detail here, and some others discussed briefly.

Tape Commands

>TAPE is used to control duplexed virtual tape systems which are defined to GDPS. See the GDPS and Tape section for details. The available parameters are:

Simply starts or stops dual copy operations.
makes the secondary VTS available for tape mount activity. This command would normally follow a Tape Stop Secondary command.
Dynamically switches the primary VTS for all composite libraries to run from Site1. If the primary VTS in any composite library is already in Site1, this command has no effect.
Same as above, except it switches the primaries to Site2.
This is the default, and switches all composite libraries to have the primary VTS in the other Site.

DASD Commands

This command starts and resynchronises mirroring. By default, START SECONDARY will issue FCSECONDARY unless you specify the optional NOFLASH parameter. It issues a CESTPATH to re-establish all the PPRC paths, and a CESTPAIR .. RESYNCH to resynchronise the mirroring on all the disks, provided they have the RESYNCH option defined in the GEOPARM.
This will Freeze all disks which are defined in the Freeze group, and Suspend all other mirrored disks. Since GDPS 2.8, this command must run on the GDPS Controlling system, not on production systems.
This script keyword will recover all secondary devices defined to GDPS and make them all simplex, for disaster or test purposes. This script command will vary all the primary volumes off line, wait 30 minutes to make sure they are off, then vary the secondaries on-line. This may not suit your purposes, if you plan to test from a different LPAR to production. The command does not check the status of the production systems, so its probable that some of the vary off commands will not work, if the systems are active. This script command must also run from the GDPS controlling system, since GDPS 2.8.
Establishes a flashcopy at the Site you specify, if you have the relevant flashcopy disks defined in the Geoparm. The optional COPY parameter forces a flashcopy in COPY mode, otherwise it runs in NOCOPY mode. Its best to force a Freeze before running this command, to make sure that the data is consistent. GDPS does not allow you to flashcopy to a disk which in on-line anywhere, unlike the raw FlashCopy commands.
This will withdraw an existing flashcopy from the Primary or Secondary Site, assuming the disks are defined to GDPS, and flashcopy is active.
This command is designed for a planned takeover, and changes the mirroring direction. It basically issues CDELPAIR for all volumes, then CDELPATH all paths. Then it issues a VARY OFFLINE for the old primary volumes, does a CESTPATH to redefine the paths in the reverse directions, does a CESTPAIR (NOCOPY), then VARY ONLINE all the new primary volumes. Again, there is a 30 minute delay to make sure all the volumes come offline, and it assumes that no production systems are running.
This is an older command which is replaced by hyperswap. It allows Site switching while systems are active.
This command basically swaps the primary and secondary disks and runs PPRC in the reverse direction. When the command completes all devices will be back in DUPLEX state and the applications will be using the former secondaries when the swap completes. The advantage of this script over DASD='SWITCH DELPAIR' is that this one is non-disruptive.
This command swaps over the primary and secondary devices, establishes PPRC in the reverse direction, then suspends PPRC. When the command completes, all the applications (which have never stopped) will be running from the secondary devices, and the primary disks will be in PPRC SUSPEND status. That is, they will not be accessable from any LPAR.
This command swaps over the primary and secondary devices, establishes PPRC in the reverse direction, then terminates PPRC. When the command completes, all the applications (which have never stopped) will be running from the old secondary devices, and the old primary disks will be in SIMPLEX status. The old primaries can be accessed from an LPAR which is not in the GDPS sysplex.

All Scripts that include a DASD SWITCH command can only be executed on a GDPS Controlling system. Typically, you would use SWITCH HYPERSWAP SUSPEND to carry out maintenance on your primary disks, then SWITCH HYPERSWAP RESYNCH to go back to the primary site. After a hyperswap, you need to use an IPLPARM command to ensure that GDPS will IPL from the correct disks, then a SYSPLEX CDS switch command, as the CDS datasets are not mirrored.


  • COMM='text'. This is simply a comment line of up to 63 characters, to explain what the script is doing. The first command in every script must be COMM, and more can be added throughout the script. The COMM command does not issue any external messages or prompts.
  • ASSIST='text' is used to communicate with the operators, and give them the option to control the actions of a script. The assist command puts a message on the ops console, with a WTOR. If the Ops reply 'OK' to the WTOR the script will continue, while a 'NOK' reply will terminate the script.
  • MESSAGE='text' is also used to communicate, but this command does not have an associated WTOR, it supplies information only.

External Commands

  • The EXECUTE command takes the external control concept a bit further. It can be used to execute an external REXX program, and will wait for the REXX program to complete, then check the return code. EXECUTE can also be used to run Netview commands, and to automatically start application systems on a standbye LPAR, if the normal LPAR is down.
  • USERPROC will run any NetView command, but it must run on the same MVS system as the script. The script will check the return code from the command, and if it is greater then 7, the Operators get a WTOR asking them if the script should proceed.

System Commands

  • CBU is used to add, or remove backup processing units from a CPC.
  • GETSTORAGE lparname will issue an MVS CONFIG command to the named lpar to define storage defined in storage element 1.
  • RELSTORAGE lparname will issue an MVS CONFIG command to system lparname to release storage defined in storage element 1.
  • IPLTYPE can be used to control what type of IPL will happen next on a given system.
  • NETOWNER command can be used to set a particular LPAR as the network owner, and activate all major nodes defined in it. It can also be used to switch NCPs with the NCPSWITCH parameter.
  • The SYSPLEX command has a large set of parameters, which permit remote IPLing, switching coupling datasets and coupling facilities, and much more.

back to top