How a ‘CM1 SL1 - ACK’ Input Message Sent to IMS Connect Works
11/26/2019 1:56:19 PM |
By Subhasish Sarkar
For Synclevel 1 (SL1), when the OTMA client gets the reply message, it must send an acknowledgement (ACK) for the syncpoint to continue. However, the OTMA client should still not process the reply message until it receives the de-allocate response. In short, for SL1, the OTMA client must send an ACK/negative acknowledgement (NAK) for the output/reply message.
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 three images in order to understand in detail what exactly happens when an IMS Connect Client sends a CM1 SL1 - ACK input message to IMS Connect. Here, we consider the case of a successfully completed syncpoint.
Pictorial representation of what happens when an IMS Connect client sends a CM1 SL1 - ACK input message to IMS Connect.
Below is a step-by-step explanation of what happens when an IMS Connect client sends a CM1 SL1 - ACK input message to IMS Connect:
1. An IMS Connect Client sends a CM1 SL1 input message to ICON
2. IMS Connect allocates a control block for the client (SVT), if it does not already exist and sends the input message to IMS OTMA via XCF. The transaction pipe (tpipe) name would be the port number that received the input message.
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.
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 anchored on the TIB
7. The IMS application program reaches a syncpoint (GU IOPCB, ISRT to IOPCB)
8. IMS OTMA retrieves the reply message from the message queue (please refer to Step 5 above)
9. IMS OTMA sends the reply message to IMS Connect via XCF. IMS OTMA then waits for an ACK/NAK. Syncpoint processing, database locks and external subsystem (Db2, MQ, etc.) locks are held and the Message Processing Region (MPR) remains occupied.
10. IMS Connect anchors the reply message on the SVT
11. IMS Connect sends the reply message to the IMS Connect client and waits for the ACK/NAK
12. The IMS Connect client gets the reply message and sends an ACK
13. The IMS Connect client holds the reply message and waits for the DeAllocate message to see if the Syncpoint completed successfully
14. IMS Connect sends the ACK to OTMA
15. Syncpoint proceeds - OTMA starts processing the syncpoint. Phase 1 and Phase 2 syncpoints begin.
16. Phase 1 Syncpoint completes successfully
17. OTMA sends the “De-Allocate Confirm” message to IMS Connect
18. OTMA deletes the TIB control block
19. Phase 2 Syncpoint completes successfully
20. IMS Connect sends the “De-Allocate Confirm” message to the IMS Connect client
21. If a persistent socket is in use, IMS Connect keeps the connection open and does not free the SVT control block; otherwise, the SVT control block is freed
22. The ICON client processes the reply message