Understanding How a ‘CM0 SL1’ Input Message Sent to IMS Connect Works in the Case of a Client NAK

IMS Connect (ICON) is the TCP/IP gateway for IMS. So, besides running the traditional IMS transactions on z/OS, an IMS programmer/database administrator (DBA) can now leverage applications running on the distributed side of the world (a Java web application, for example) to be able to easily talk to IMS databases.

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:

1. An IMS Connect Client sends a CM0 SL1 input message to ICON
2. 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.
3. 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.
4. 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.
5. Next, the IMS transaction inserts (ISRT) the reply message to the IOPCB
6. The reply message is enqueued on a temporary queue
7. The IMS application program reaches a syncpoint (GU IOPCB, ISRT to IOPCB)
8. Syncpoint proceeds
9. OTMA enqueues the reply message on a QAB (Queue Anchor Block)
10. Syncpoint is successful
11. Syncpoint completes
12. IMS OTMA does an internal GU to retrieve the reply message from the IMS message queue
13. IMS OTMA sends the reply message to IMS Connect via XCF
14. IMS Connect anchors the reply message on the SVT control block
15. IMS Connect sends the reply message to the IMS Connect Client; IMS Connect waits for the ACK/NAK reply from the client
16. The IMS Connect Client gets the reply message from IMS Connect and sends a NAK reply message back to IMS Connect
17. The IMS Connect Client notifies the user
18. IMS Connect sends the NAK message to OTMA
19. OTMA re-queues, or purges, or reroutes the reply message

To conclude, IMS Connect sends the output/reply message to the ICON client and waits for the ACK/NAK from the ICON client. Once IMS Connect receives the ACK/NAK from the ICON client, it sends the ACK/NAK to OTMA. There is a timeout feature in OTMA while waiting for the ACK/NAK. The ICON client receives another output/reply message after IMS Connect receives the de-allocate message from OTMA (unless in conversation).
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.

---