XRF processing and OTMA

XRF supports OTMA.

Recommendation: The active and alternate IMS subsystems should be in the same z/OS® cross-system coupling facility (XCF) group. If they are not in the same XCF group, after an XRF takeover, the client must connect to the new XCF group. If they are in the same XCF group, after an XRF takeover, the client is automatically reconnected to the XCF group.

The active IMS joins the XCF group specifying the IMS USERVAR name as its member name. The alternate IMS joins the group only after an XRF takeover, and connects using the same USERVAR name as the member name. If the active and XRF alternate subsystems are in the same XCF group, during XRF takeover, the new active IMS:

Ensures that the old IMS member is disconnected
Rejoins the group
Begins delivering any queued output destined for an OTMA client, following client-bid processing for that client

IMS XRF does not track the /START OTMA and /STOP OTMA commands. The IMS procedures for both the active and alternate IMS should both specify OTMA=Y in order to ensure that IMS automatically rejoins the XCF group during XRF takeover.

In an XRF environment, OTMA clients are equivalent to Class 3 terminals and are not automatically reconnected to IMS. The clients detect that IMS has left the XCF group and wait for IMS (or the XRF alternate) to rejoin the group. Then the clients send new client-bid requests to IMS.

The alternate system in an XRF complex does not track when resynchronization has begun or the resynchronization of a particular tpipe. If IMS fails during resynchronization, the client should detect the IMS failure, and try to resynchronize with the new XRF active system.