Optimize IMS Performance and Availability Using OTMA and Shared Queues
For more than 40 years, the IBM Information Management System (IMS) has built an unparalleled reputation for availability and performance—a reputation bolstered by the addition of new features that have helped eliminate planned outages and minimize the impact of unplanned outages. One of these features is the IMS shared-queues function.
This function allows multiple IMS subsystems in a z/OS Sysplex environment to share IMS transaction messages. When an IMS subsystem in a shared-queues group receives a transaction message from a client, instead of immediately processing the message itself, the receiving IMS subsystem places the message on a shared queue in a z/OS coupling facility. There, any IMS subsystem in the shared-queues group can retrieve and process the transaction. After being processed, the response message is routed back to the client through the original receiving IMS subsystem.
A shared-queues group enables the distribution of the IMS workload among multiple IMS subsystems and allows individual IMS subsystems to be taken offline for maintenance without affecting the availability of IMS to its clients.
For an IMS client, the multiple IMS subsystems in a shared-queues group appear as a single system—a highly efficient, always available IMS system.
One of the primary ways that clients submit transactions to an IMS shared-queues group is through a z/OS cross-system coupling facility (XCF) group and the IMS Open Transaction Manager Access (OTMA) protocol. OTMA is a transaction-based, connectionless client-server protocol.
After processing a transaction received through OTMA, the IMS subsystems in a shared-queues group typically return the transaction responses to the client via an I/O program communication block (IOPCB) and an OTMA client adapter, such as IMS Connect or WebSphere MQSeries. The I/O PCB is an output structure that IMS uses to return responses to a client. The IMS client does not need to be aware of the roles of OTMA, shared queues or the multiple IMS systems in an IMSplex. Again, from the client’s perspective, a single IMS system is processing its transactions. (See Figure 1.)
IMS V12, the most recent version, adds yet another enhancement to the IMS shared-queues functionality, one that supports transactions submitted to IMS through the OTMA protocol. The latest improvements include the following:
OTMA Transaction Messages
OTMA processes two types of transaction messages: commit-then-send (commit mode 0 or CM0) and send-then-commit messages (commit mode 1 or CM1). The processing requirements for each type differ in an IMS shared-queues configuration.
OTMA commit-then-send messages can be processed on any IMS subsystem in a shared queues group. IMS subsystems that did not receive the transaction directly from the client, return IOPCB output to the IMS shared-message queue with the name of the IMS subsystem that did receive the transaction from the client. If the transaction processing results in a program-to-program message switch, the switch message can also be processed on any IMS subsystem in the shared-queues group.
When the IMS default processing options are used, OTMA send-then-commit messages, on the other hand, can only be processed by the IMS subsystems that receive them directly from the client. This restriction also applies to any program-to-program message switches that the send-then-commit messages might trigger.
However, send-then-commit messages can be processed by any IMS subsystem in a shared-queues group if the default processing options are changed by coding the AOS= parameter of the DFSDCxxx member in the IMS.PROCLIB data set.
The Assist On-site (AOS) parameter has five settings that enable processing by other IMS subsystems in a shared-queues group: Y, F, B, S or X. The five settings provide a fine degree of control over when and whether RRS or XCF is used to coordinate the processing of transactions. The AOS parameter also provides control over whether IMS rejects transaction messages that require a higher degree of coordination than the AOS parameter permits or whether the processing of these transactions is restricted to the IMS subsystems that receive them directly from the client.
When using Resource Recovery Services (RRS) in a shared-queues group, RRS coordinates the synchronization of output between the IMS subsystems that receive the input from the client and the IMS subsystems that process the transactions. RRS is enabled by specifying RRS=Y in the DFSDCxxx member. When RRS is enabled, it is enabled for all IMS transactions, not just those input through OTMA.
With RRS enabled, you can specify either AOS=Y and AOS=F to use RRS to coordinate the processing of OTMA transactions on any IMS subsystem in a shared queues group, regardless of the OTMA synchronization level required by the OTMA transaction. The OTMA synchronization levels are None, Confirm, and SyncPt.
IMS V12 introduces the three newest of the five AOS settings: B, S and X. The three new settings provide better performance when processing send-then-commit transactions in a shared-queues group by enabling OTMA messages to be processed by any IMS system in a shared queues group without requiring RRS.
The following is a summary of the AOS= options:
- AOS=N: Restricts the processing of OTMA send-then-commit messages to the IMS subsystem that receives it directly from the client. This is the default.
- AOS=Y: For a shared-queues group in which all IMS systems have RRS enabled, AOS=Y enables the processing of OTMA send-then-commit messages by any IMS subsystem in a shared-queues group regardless of the OTMA synchronization level of the transaction, but only if RRS is enabled in all IMS subsystems in the shared-queues group.
- AOS=F: For a shared-queues group in which only some of the IMS systems have RRS enabled, AOS=F enables the processing of OTMA send-then-commit messages by any IMS subsystem in a shared-queues group that has RRS enabled, regardless of the OTMA synchronization level of the transaction. If an IMS system that does not have RRS enabled attempts to process the message, the message is rejected with IMS U711 abend.
- AOS=B: Enables the processing of OTMA send-then-commit messages by any IMS subsystem in a shared-queues group; however, the coordination of messages that specify a synchronization level of NONE or CONFIRM is managed by XCF and the coordination of message that specify a synchronization level of SYNCPT is managed by RRS.
- AOS=S: Enables the processing of OTMA send-then-commit messages that specify a synchronization level of NONE or CONFIRM by any IMS subsystem in a shared-queues group. Messages that specify SYNCPT can be processed only by a back-end IMS system if the back-end IMS system has RRS enabled. If a back-end IMS system that does not have RRS enabled attempts to process the message, the message is rejected with an IMS user abend 0711.
- AOS=X: Enables send-then-commit messages that specify a synchronization level of NONE or CONFIRM to be processed in any IMS subsystem in the shared-queues group. XCF is used to coordinate transactions processed by back-end systems. Messages that specify a synchronization level of SYNCPT can be processed only by the IMS systems that receive the transaction directly from the client.
A program-to-program message switch from a commit-then-send transaction, by default, must be processed on the IMS subsystem where the switch is initiated. Two exceptions to this are program-to-program switches from a conversational transaction and program-to-program switches in which either the OTMAASY=S option in the DFSPBxxx member or APPCASY=S option in the DFSDCxxx member of the IMS.PROCLIB data set is specified.