Understanding IMS OTMA Commit Mode and Synchronization Level
The IMS OTMA client communicates information to IMS and receives information from IMS in a prefix passed in front of the message (or command). Among several information present in the prefix are COMMIT MODE and SYNCHRONIZATION (SYNC) LEVEL.
OTMA SYNC Level
The OTMA client specifies the sync level on each input message. The OTMA sync level determines how the OTMA client acknowledges output messages. It doesn’t apply to how OTMA acknowledges input messages.
There are three different OTMA synchronization levels:
- Synclevel 0 (SL0): The OTMA client doesn’t have to acknowledge the output message by sending either an Acknowledgement (ACK) or a Negative Acknowledgement (NAK) message.
- Synclevel 1 (SL1): The OTMA client must send an ACK/NAK message for the output message.
- Synclevel 2 (SL2): The OTMA client participates in a two-phase commit. SL2 is supported by IMS Connect (ICON) and IMS TM Resource Adapter. IMS Connect is an IBM provided OTMA client for TCP/IP.
OTMA Commit Mode
Like the sync level, the OTMA client specifies the OTMA commit mode on each input message. The OTMA commit mode determines how the Input Output Program Communications Block (IOPCB) output messages are sent.
There are two different OTMA commit modes:
1. Commit Mode 1 (CM1)
CM1 is also known as “Send-then-Commit.” The IOPCB output is sent by IMS first. IMS may wait for an ACK message before the syncpoint is complete. For SL0, IMS doesn’t expect an ACK message and continues with the syncpoint. For SL1, IMS waits for an ACK/NAK message before continuing with the syncpoint. For SL2, IMS waits for an ACK/NAK message plus response from the Resource Recovery Services (RRS) before continuing with the syncpoint. RRS provides a global syncpoint manager that any resource manager on z/OS can exploit.
CM1 increases region occupancy. The output messages are not queued but anchored on a Transaction Instance Block (TIB) control block. If the output message can’t be sent to the client or is NAK’ed by the client in case of SL1, the transaction abends with U0119 and backs out.
For SL0, the OTMA client receives the output message even before the syncpoint is complete. However, the OTMA client shouldn’t process the message until it receives a “deallocation” message (“Commit Confirm” or “De-allocate Confirm”) from the OTMA. The “deallocation” message indicates the status of the syncpoint. A “Commit Confirm” or “De-allocate Confirm” message indicates that the syncpoint has completed successfully. On the other hand, a “Commit Abort” or “De-allocate Abort” message indicates that the syncpoint hasn’t completed successfully.
If the syncpoint didn’t complete successfully, the output message should be discarded by the OTMA client. IMS Connect does this and sends an error message to the ICON client.
For SL1, the OTMA client receives the output message and must send an ACK message for the syncpoint to continue. However, the OTMA client shouldn’t still process the output message until it receives the “deallocation” response message. IMS Connect sends the output message to the IMS Connect client and waits for the ACK message from the ICON client. Upon receipt of the ACK message, IMS Connect sends it to the OTMA. There is a timeout feature in OTMA while waiting for the ACK message. OTMA sends the de-allocate response message to IMS Connect which then forwards it to the IMS Connect client. RC4, Reason Code x’97’ indicates that a “de-allocate confirmed” response message was received by the IMS Connect client, whereas RC4, Reason Code x’96’ indicates that the IMS Connect client has received a “de-allocate abort” response message.
2. Commit Mode 0 (CM0)
CM0 is also known as “Commit-then-send.” The output message is queued and IMS sends the output message only after the syncpoint is complete. The output message is queued on a Queue Anchor Block (QAB) control block. For SL1, an ACK message is always required by the OTMA for it to dequeue the output message. ALTPCB output messages are always CM0.
In IMS Version 11, a Timeout feature was introduced while waiting for an ACK message for a CM0 SL1 output message. The output message queue is held for the duration of an ACK message not been received within the specified timeout value. When the timeout is reached, the output message causing the hang is moved to a special timeout queue Transaction PIPE (TPIPE) for that TMEMBER, and the original held output queue is freed. The same timeout value is used for both CM0 and CM1 ACK timeouts.
In IMS Connect, an IMS Connect OTMA client can specify a CM0 ACK timeout TPIPE name during the client bid. IMS Connect has the CM0ATOQ parameter on the HWS control card in the HWSCFGxx member and Datastore control card, which specifies the TPIPE name. The default TPIPE name is DFS$$TOQ.
For IMS Connect, the output message is queued on to a Hold queue. If a Reroute TPIPE name was specified on the input message, the output message is queued on to that TPIPE; if a Reroute TPIPE name was not specified, the output message is queued on to the TPIPE name specified in the CM0ATOQ parameter, and if this parameter was also not set, the output message is queued on to the TPIPE DFS$$TOQ.
All information in this article is provided to you “as is” and represents the views of the authors. TechChannel cannot guarantee or imply absolute reliability, serviceability or function of the information herein.