Sharing asynchronous commit-then-send output: the OTMA super member function

Hold-queue-capable OTMA clients, such as IMS Connect, can share asynchronous commit-then-send (CM0) output messages by enabling the OTMA super member function. The OTMA super member function is specifically designed to support multiple instances of IMS Connect in a z/OS® Sysplex Distributor environment.

The OTMA super member function manages all of the asynchronous CM0 output of all of its participating OTMA clients by using a common output queue. Any participating hold-queue-capable client can then retrieve the CM0 messages on the super member output queue by issuing its own RESUME TPIPE call, regardless of which client the CM0 output was originally destined for.

The messages on the super member queue are retrieved on a first-in-first-out basis, without regard to which instance of the OTMA client originated the output or which instance of the OTMA client issued the RESUME TPIPE call.

The RESUME TPIPE call from a participating OTMA client does not need to specify anything about the super member. The super member function recognizes the RESUME TPIPE call as coming from a participating OTMA client and returns the output on the common queue.

You can register the participation of an instance of IMS Connect in the super member function by specifying the super member name on the SMEMBER parameter of the IMS Connect HWS configuration statement.

To use the OTMA super member in a configuration that includes multiple IMS systems, you must have shared queues enabled for all the IMS systems. If a shared queues back-end IMS creates ALT-PCB output in the super member-enabled environment, the output can be retrieved from any front-end IMS with an OTMA client in the super member set. All retrieval options of the resume tpipe call are supported in the shared queues environment.

If there is only one IMS system with multiple OTMA clients, shared queues support is not required.

To activate the super member function specify a 1- to 4-character super member name in the SMEMBER parameter of the HWS configuration statement in the IMS Connect configuration member (HWSCFGxx). Super member names must be unique and cannot be the same as existing OTMA member names.

The first instance of IMS Connect that specifies a super member name both activates the super member function and defines the name of the super member for all other instances of IMS Connect. Any instances of IMS Connect activated subsequently that are to use the same super member queue must specify that same super member name as specified by the first instance of IMS Connect.

You can display the name of an activated super member by issuing any one of the following IMS Connect commands:
  • The IMS type-2 format command QUERY IMSCON TYPE(CONFIG)
  • The WTOR format command VIEWHWS
  • The z/OS MODIFY format command QUERY MEMBER TYPE(IMSCON)

To display additional information about a super member, you can also issue the IMS commands /DISPLAY OTMA and /DISPLAY TMEMBER TPIPE.

When you issue the OTMA commands /START TMEMBER TPIPE, /STOP TMEMBER TPIPE, or /TRACE TMEMBER TPIPE with a regular OTMA member specified, OTMA expands the scope of the command to include any related super member.

You can also issue OTMA commands directly to an existing super member. For example, you can dequeue asynchronous messages from a super member by issuing the command /DEQUEUE TMEMBER supermember_name TPIPE tpipe_name PURGE.

Asynchronous output messages that are created by ALT-PCB processing are stored in the super member directly. If the input messages are submitted through an IMS Connect that supports the super member, the input parameter lists for the OTMAYPRX user exit and DFSYDRU0 exit routine contain a flag indicating that the message is from a super member supported client. Also, the OTMA state data prefix pointed to by the input parameter list contains the super member name, if any.