By Ben Johnson and Jack Yuan
To fully benefit from the availability, scalability, and performance advantages provided by z/OS Sysplex Distributor, IMS provides a super member function that enables multiple, redundant instances of IMS Connect, the integrated
Figure 1. Sysplex Distributor environment with the super member function enabled
A super member is an OTMA structure that manages all asynchronous output and synchronous callout messages for multiple instances of IMS Connect. Any instance of IMS Connect that joins the super member group can share and retrieve the asynchronous output or synchronous callout messages. With the super member solution, users connecting to IMS through Sysplex Distributor and multiple instances of IMS Connect can now enable true workload balancing and protect themselves from a single point of failure without risking the temporary loss of asynchronous output or synchronous callout messages.
The super member stores all of the asynchronous output messages and synchronous callout messages for all instances of IMS Connect in the super member group. Any instance of IMS Connect in the super member group can then retrieve the messages from the super member, regardless of whether the output was generated by another IMS Connect instance or by a callout request from an IMS application. An instance of IMS Connect that is not a part of a super member group can only retrieve messages that are specifically destined for that instance of IMS Connect.
The super member solution is transparent to the end user. The end user does not need to know that a connection is to a super member instead of an instance-specific OTMA member. The super member solution also frees the end user from having to know which instance of IMS Connect can retrieve the output messages.
IMS Connect activates the super member function and joins a super member group by specifying a super member name on the SMEMBER= parameter in either or both of the
Here are some tips for using the super member function:
- You can use the super member function in a shared queues environment to share output across multiple instances of IMS Connect that are connected to multiple IMS systems. Without shared queues and the super member function, the IMS Connect and IMS instances cannot share the output.
- Any asynchronous output queued to an OTMA tpipe on an IMS system that IMS Connect is connected to directly automatically becomes available to the super member group; however, any existing
ALT-PCB output on the back-end IMS remains inaccessible unless IMS Connect connects to the back-end directly to retrieve the messages. New ALT-PCB output messages on back-end IMS systems can become accessible to the IMS Connect instance after it joins the super member group if V10 APARs PK61174 and PK84540 are applied.
- Synchronous callout messages are queued to the super member tpipe and delivered to the client one at a
time, in the order that they are received; however, the responses to the callout messages might not return to IMS in the same order.
- The queue name associated with messages on a shared queues super member queue always remains the same, even after a cold start. Because the queue name is constant, dequeuing the message when necessary is much easier. Super member queue names are made up of the 8-byte tpipe name and the 4-byte super member name.
- In a shared queues environment, you can use the OTMA destination descriptors (introduced in IMS Version 10) or the DFSYPRX0 and DFSYDRU0 user exits to route
ALT-PCB output messages from back-end IMS systems to a super member. Messages queued to a super member do not have system affinity and can be retrieved by any IMS Connect instance that is connected to a front-end IMS system.
- If super member messages are moved to a shared queues overflow structure, you can identify the super member messages by the super member name and tpipe name by issuing the /DISPLAY VERFLOWQ STRUCTURE command. Because the output messages queued to a super member do not have affinity to any IMS subsystem, no IMS ID is displayed.
- When IMS Multiple Systems Coupling (
MSC) networks and IMSplexes coexist, OTMA transactions that process in a shared-queues back-end IMS system can issue a CHNG call to a modifiable PCB with an OTMA destination. In this scenario, applying V10 APAR PK95884 will ensure that when the OTMA Destination Resolution exit routine (DFSYPRX0) or the OTMA User Data Formatting exit routine (DFSYDRU0) are called at the back-end IMS, they will receive the OTMA prefix information and the output will be queued to the super member queue.