How a CM1 SL0 Input Message Sent to IMS Connect Works
11/13/2019 8:37:28 AM |
By Subhasish Sarkar
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. CM1 refers to Commit Mode 1, which is the “Send-then-Commit” Commit Mode. SL0 refers to Synclevel 0 which means that the output message is not acknowledged by the OTMA client.
IMS Connect is an IBM provided OTMA client for TCP/IP. 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 CM1 SL0 input message to IMS Connect. Here, we consider the case of the Syncpoint completing successfully. In the following diagrams, IMS Connect has been referred to as ICON.
Pictorial representation of what happens when an IMS Connect client sends a CM1 SL0 input message to IMS Connect.
Below is a step-by-step explanation of what happens when an IMS Connect client sends a CM1 SL0 input message to IMS Connect:
1. An IMS Connect Client sends a CM1 SL0 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, application program termination)
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 and deletes it from the IMS message queue
10. IMS Connect anchors the reply message on the SVT and waits for the De-Allocate (“deallocation”) message from OTMA. Remember that for CM1, SL0, even though the OTMA client (IMS Connect, in our case) receives the message before the syncpoint is complete, it should not process the message until it receives a “deallocation” message (“De-Allocate Confirm” message) from OTMA, indicating the status of the syncpoint.
11. Syncpoint proceeds- OTMA starts processing the syncpoint. Phase 1 and Phase 2 syncpoints begin.
12. Syncpoint processing completes successfully Phase 1 syncpoint ends
13. OTMA sends the De-Allocate Confirm message to IMS Connect (not if Conversation)
14. OTMA deletes the TIB control block (not if Conversation) and frees the input message. OTMA frees the disk relative record number (DRRN) of the message. DRRN is the actual address of the message within the IMS message queue.
15. Syncpoint completes- Phase 2 syncpoint ends
16. IMS Connect sends the reply message to the IMS Connect client
17. 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
18. The ICON client processes the reply message