availability" /> Use the z/OS Extended Recovery Facility (XRF)

 

Using the z/OS Extended Recovery Facility (XRF)

We can use WebSphere MQ in an extended recovery facility (XRF) environment. All WebSphere MQ-owned data sets (executable code, BSDSs, logs, and page sets) must be on DASD shared between the active and alternate XRF processors.

If you use XRF for recovery, stop the queue manager on the active processor and start it on the alternate. For CICS, we can do this using the command list table (CLT) provided by CICS, or the system operator can do it manually. For IMS, this is a manual operation and do it after the coordinating IMS system has completed the processor switch.

WebSphere MQ utilities must be completed or terminated before the queue manager can be switched to the alternate processor. Consider the effect of this potential interruption carefully when planning your XRF recovery plans.

Take care to prevent the queue manager starting on the alternate processor before the queue manager on the active processor terminates. A premature start can cause severe integrity problems in data, the catalog, and the log. Using global resource serialization (GRS) helps avoid the integrity problems by preventing simultaneous use of WebSphere MQ on the two systems. You must include the BSDS as a protected resource, and include the active and alternate XRF processors in the GRS ring.