z/OS Global Mirror

z/OS Global Mirror, or XRC - eXtended Remote Copy as it used to be called, is a mainframe only product. Synchronous Metro Mirror is probably the mirroring product of choice for mainframe disks, if the distance between sites is less than 30km, but what if your sites are 3000km apart? z/OS Global Mirror is an asynchronous mirroring product that works over long distances. Data is mirrored to a remote site, but it will generally be a little behind the data at the primary site. Unlike Metro Mirror, It is software driven from an z/OS host. It uses System Data Mover (SDM) to copy the writes. SDM runs as an pair of z/OS started tasks. z/OS Global Mirror uses a set of files to control and correctly sequence the writes. If z/OS Global Mirror runs over more than one CEC, a sysplex timer is used to correctly timestamp the updates. All primary and secondary volumes must be online to the SDM system

In brief, z/OS Global Mirror gets involved after data is written to the primary cache (at which point the application IO is complete). The records are held in SDM datasets, where they are grouped together to maintain correct time sequence, then journalled. Then the data is written off to the secondary disks.

Its possible for the secondary writes to lag quite a bit behind the primary. If this happens, you can slow the primary IOrate down for a while to let the secondary catch up.

z/OS Global Mirror has the ability to suspend IO temporarily for DR testing.

Dataset issues

For SYSPLEX datasets its best to mirror the LOGR and WLM datasets, as you don't want to switch to your secondary site with no WLM policies, and you don't want to lose your logs either. How busy is your CFRM file? If its very busy, consider not mirroring it. Its also best if the XCF at DR does not know about the original Coupling facilities. It will get upset if it thinks they are dead.
At DR, consider creating brand new CFRM and SYSPLEX couple data sets and cold starting the sysplex. SYS1.PARMLIB will be mirrored, so XCF will find the old coupling datasets in the COUPLExx member. You need procedures to decide how to reply to the WTORs which will come up at IPL time, but once you chose the new datasets, all will come up clean.

Some system datasets need to be available, but the content is not critical. Examples are Page Datasets, SMF and SYSRES. You could remote copy them to establish them at the new site, but then suspend them.

However, remember that if you're running with the XRC Datamover at your remote site, then ALL data goes down the link, even that from suspended volumes. Only when it gets to the DataMover is it discarded. Consider using the XRC COPY facility on selected volumes on a regular basis, during a low activity period, then DROP the volumes from the XRC session to save the bandwidth

Other hints

If you do mirroring and backup to a remote site, try to keep XRC and backup links in separate fibres, otherwise your backups could saturate the links.

How do you check if mirroring is working? You can issue CQUERY TSO commands in REXX, but they echo the commands and results to the SYSLOG. Another option is to use an API to issue the Metro Mirror and z/OS Global Mirror requests and get the responses back. You can get them in the exact TSO message format or in a "unformatted" mode that is easier to process. The ANTRQST macro is documented in DFSMSdfp 1.5 Advanced Services

z/OS Global Mirror statistics are contained in SMF record 42 subtype 11

DR angle

To invoke DR (or simulated disaster, for testing), issue a XRECOVER command to the Data Mover and in about a minute, the DASD at the recovery site will be re-labeled, and all the data is available. You might have to recover or recreate those few volumes which you don't mirror. Then you IPL, CLPA and cold-start JES2.

back to top