Understanding How a ‘CM0 SL1’ Input Message Sent to IMS Connect Works in the Case of a Client NAK
A detailed explanation of what happens when an IMS Connect Client sends a CM0 SL1 input message to IMS Connect and a client Negative Acknowledgement (NAK) occurs
By Subhasish Sarkar01/15/2021
The Java web application would go through IMS Connect to IMS as an Open Transaction Manager Access (OTMA) transaction. COMMIT MODE and SYNCHRONIZATION (SYNC) LEVEL are some protocols that OTMA clients must stick to. CM0 stands for Commit Mode 0, which is the “Commit-then-Send” Commit Mode. Similarly, SL1 stands for SYNC LEVEL 1.
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 the information present in the prefix are COMMIT MODE and SYNC LEVEL.
Let’s look at Figure 1 in order to understand in detail what exactly happens when an IMS Connect Client sends a CM0 SL1 input message to IMS Connect and a client Negative Acknowledgement (NAK) occurs.
Figure 1: Pictorial representation of what happens when an IMS Connect client sends a CM0 SL1 input message to IMS Connect and a client NAK occurs
Below is a step-by-step explanation of what happens when an IMS Connect client sends a CM0 SL1 input message to IMS Connect and a client NAK occurs:
- An IMS Connect Client sends a CM0 SL1 input message to ICON
- IMS Connect builds an SVT control block for the client, if it doesn’t already exist and sends the input message to IMS OTMA via Cross-System Coupling Facility (XCF). The transaction pipe (TPIPE) name is the Client ID.
- OTMA processes the input message. It allocates the Transaction Instance Block (TIB) control block. RACF or any other System Authorization Facility (SAF) product is called, if needed. The input message is first inserted into the IMS message queue and then enqueued on the transaction queue. After the input message has been enqueued on the transaction queue, OTMA frees the TIB control block.
- The IMS transaction does a Get-Unique (GU) to the Input Output Program Communications Block (IOPCB) to retrieve the input message. The input message is then processed by the IMS transaction application program as per the existing logic.
- Next, the IMS transaction inserts (ISRT) the reply message to the IOPCB
- The reply message is enqueued on a temporary queue
- The IMS application program reaches a syncpoint (GU IOPCB, ISRT to IOPCB)
- Syncpoint proceeds
- OTMA enqueues the reply message on a QAB (Queue Anchor Block)
- Syncpoint is successful
- Syncpoint completes
- IMS OTMA does an internal GU to retrieve the reply message from the IMS message queue
- IMS OTMA sends the reply message to IMS Connect via XCF
- IMS Connect anchors the reply message on the SVT control block
- IMS Connect sends the reply message to the IMS Connect Client; IMS Connect waits for the ACK/NAK reply from the client
- The IMS Connect Client gets the reply message from IMS Connect and sends a NAK reply message back to IMS Connect
- The IMS Connect Client notifies the user
- IMS Connect sends the NAK message to OTMA
- OTMA re-queues, or purges, or reroutes the reply message
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.
Subhasish Sarkar (SS) is an IBM Z Champion and a Senior SQA engineer at BMC software.
Sponsored ContentAchieve Compliance Without Impacting Productivity