Understanding how a ‘CM0 SL1 – ACK’ Input Message sent to IMS Connect works

IMS Connect (ICON) is the TCP/IP gateway for IMS. So, besides running the traditional IMS transactions on z/OS, an IMS programmer/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 OTMA (Open Transaction Manager Access) transaction. COMMIT MODE and SYNCHRONIZATION (SYNC) LEVEL are some protocols that OTMA clients have to stick to. CM0 stands for Commit Mode 0, which is the “Commit-then-Send” Commit Mode. Similarly, SL1 stands for SYNCHRONIZATION (SYNC) LEVEL 1 and how all these things gel up together has been well explained in the article.

The IMS Open Transaction Manager Access (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 SYNCHRONIZATION (SYNC) LEVEL. CM0 stands for Commit Mode 0, which is the “Commit-then-Send” Commit Mode.

IMS Connect (ICON) will send the output/reply message to the ICON client and wait for the ACK from the ICON client, which is then sent to OTMA. There is a timeout feature in OTMA while waiting for the ACK. The ICON client will get another output/reply message after IMS Connect receives the de-allocate message from OTMA (unless in conversation).

Let us first look at the following two images in order to understand in detail what exactly happens when an IMS Connect Client sends a CM0 SL1 – ACK input message to IMS Connect.

Pictorial representation of what happens when an IMS Connect client sends a CM0 SL1 – ACK input message to IMS Connect.

Below is a step-by-step explanation of what happens when an IMS Connect client sends a CM0 SL1 – ACK input message to IMS Connect:

1. An IMS Connect Client sends a CM0 SL1 input message to IMS Connect (ICON).
2. IMS Connect builds a control block (SVT Control Block) for the client, if it does not already exist and sends the input message to IMS OTMA via XCF (Cross-System Coupling Facility). The transaction pipe (tpipe) name would be the Client ID.
3. OTMA processes the input message. A control block called a Transaction Instance Block (TIB) is allocated. 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 application program 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 application program as per the existing logic.
5. The application program then does an Insert (ISRT) of 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 and waits for the ACK/NAK reply from the client.
16. The IMS Connect Client gets the reply message from IMS Connect and sends an ACK reply message back to IMS Connect.
17. The IMS Connect Client can then go ahead and process the reply message.
18. IMS Connect sends the ACK reply message to OTMA via XCF.
19. OTMA can then safely go ahead and dequeue the reply message.