IMS Connect client call flows

The following examples show flows for IMS Connect client conversational and non-conversational transactions.

All sample flows shown apply to both persistent and transaction TCP/IP sockets, and all flows use this protocol: commit mode 1 (send-then-commit), synch level = confirm, with ACK and NAK.

The following sample flows are illustrated:
  • Non-conversational, running to successful completion using ACK
  • Conversational, running to successful completion using ACKs
  • Non-conversational, where client sends NAK in response to message
  • Conversational, where client sends NAK in response to one of the messages
  • Non-conversational, terminated by Host application before successful completion of transaction
  • Conversation terminated by Host application before successful completion of transaction

Non-conversational, running to successful completion using ACK

The following example shows a non-conversational flow with commit mode=1, synch level=confirm, and ACK (transaction runs to successful completion).

CLIENT                  FLOW               IMS CONNECT
REQUEST                                      REQUEST

  SEND---------------->IRM/TRAN/DATA ----------->RECEIVE
  RECEIVE<----------------DATA/CSM<--------------SEND
  SEND-------------------->IRM/ACK-------------->RECEIVE

  RECEIVE<-------------------RSM<----------------SEND DEALLOCATE CONFIRM
       RSM reason code = DEALLOCATE CONFIRM  X'61' (97)
     (97 = IMS Host application has committed the transaction)

Conversational, running to successful completion using ACKs

The following example shows a conversational flow with commit mode=1, synch level=confirm, and ACK (transaction runs to successful completion).

CLIENT                  FLOW               IMS CONNECT
REQUEST                                      REQUEST

  SEND---------------->IRM/TRAN/DATA ----------->RECEIVE
  RECEIVE<-------------- DATA/CSM<---------------SEND
  SEND------------------->IRM/ACK--------------->RECEIVE
  SEND------------------->IRM/DATA-------------->RECEIVE
  RECEIVE<----------------DATA/CSM<--------------SEND
  SEND-------------------->IRM/ACK--------------->RECEIVE
                             .
                             .                            
                             .
  SEND------------------->IRM/DATA ------------->RECEIVE
  RECEIVE<----------------DATA/CSM<--------------SEND

  SEND------------------->IRM/ACK--------------->RECEIVE

  RECEIVE<------------------RSM<-----------------SEND DEALLOCATE CONFIRM
         RSM reason code = DEALLOCATE CONFIRM  X'61' (97)
     (97 = IMS Host application has committed the transaction)

Non-conversational, where client sends NAK in response to message

The following example shows a non-conversational flow with commit mode=1, synch level=confirm, and NAK (transaction terminates with a NAK from client application).

CLIENT                  FLOW               IMS CONNECT
REQUEST                                      REQUEST

  SEND---------------->IRM/TRAN/DATA ----------->RECEIVE
  RECEIVE<----------------DATA/CSM<--------------SEND
  SEND-------------------->IRM/NAK-------------->RECEIVE

  RECEIVE<----------------------------------- IMS MESSAGE "DFS555.."

Conversational, where client sends NAK in response to one of the messages

The following example shows a conversational flow with commit mode=1, synch level=confirm, and NAK (transaction terminates with a NAK from client application).

CLIENT                  FLOW               IMS CONNECT
REQUEST                                      REQUEST

  SEND---------------->IRM/TRAN/DATA ----------->RECEIVE
  RECEIVE<-------------- DATA/CSM<---------------SEND
  SEND-------------------->IRM/ACK--------------->RECEIVE
  SEND------------------->IRM/DATA-------------->RECEIVE
  RECEIVE<----------------DATA/CSM<--------------SEND
  SEND------------------->IRM/ACK--------------->RECEIVE
                             .
                             .
                             .
  SEND------------------->IRM/DATA-------------->RECEIVE
  RECEIVE<----------------DATA/CSM<--------------SEND
  SEND------------------->IRM/NAK--------------->RECEIVE

  RECEIVE<----------------------------------- IMS MESSAGE "DFS555.."

Non-conversational, terminated by Host application before successful completion of transaction

The following example shows a non-conversational flow with commit mode=1, synch level=confirm, and ACK (transaction terminated by host application before successful completion).

 CLIENT                  FLOW               IMS CONNECT
 REQUEST                                      REQUEST

  SEND---------------->IRM/TRAN/DATA ----------->RECEIVE
            Host Application abnormally terminates
  RECEIVE<----------------------------------- IMS MESSAGE "DFS555.."

Conversation terminated by Host application before successful completion of transaction

The following example shows a conversational flow with commit mode=1, synch level=confirm, and NAK (transaction terminated by host application).

CLIENT                  FLOW               IMS CONNECT
REQUEST                                      REQUEST

  SEND---------------->IRM/TRAN/DATA ----------->RECEIVE
  RECEIVE<---------------DATA/CSM<---------------SEND
  SEND------------------->IRM/ACK--------------->RECEIVE

  SEND------------------->IRM/DATA-------------->RECEIVE
  RECEIVE<----------------DATA/CSM<--------------SEND
  SEND-------------------->IRM/ACK-------------->RECEIVE
                              .
                              .
                              .
  SEND------------------->IRM/DATA-------------->RECEIVE
  RECEIVE<----------------DATA/CSM<--------------SEND
  SEND-------------------->IRM/ACK-------------->RECEIVE

            Host Application abnormally terminates

  RECEIVE<----------------------------------- IMS MESSAGE "DFS555.."

IMS Connect client message protocol sequence for IMS DFS messages and IMS command output

Table 1 and Table 2 show the required actions to be taken when different IMS DFSnnnnn messages or IMS command output is sent to the IMS Connect client. The two tables illustrate whether or not an ACK is required to be sent when the client receives an IMS DFS message or output from an IMS command, both for synch level Confirm and synch level None and for commit mode 0 (CM0) and commit mode 1 (CM1).
Note: The client code can test the CSM_FLG1 byte for the presence of the CSM_ACK_NAK flag; it can also test the RSM_FLG1 byte for the presence of the RSM_ACK_NAK flag. It performs this test to determine if an ACK or NAK is required. Otherwise, it performs the analysis outlined in Table 1 and Table 2.
Table 1 and Table 2 also define whether or not the client requires a READ in order to receive the "Deallocate Abort" response (RSM) from IMS Connect. Notes for both tables immediately follow Table 2.
Table 1. Persistent sockets: client message protocol sequence for IMS DFS messages and IMS command output
Message output to client CM1, Synch level confirm CM1, Synch level none CM0, Synch level confirm CM0, Synch level none
Invalid transaction code DFS064 DFS0641 DFS0641 N/A N/A
Transaction stopped DFS065 DFS0651 DFS0651 N/A N/A
Transaction abended DFS555 DFS5557 DFS5551 N/A N/A
Output DFS2082 DFS20822 DFS20821 N/A N/A
IMS Command Output Cmd output1 Cmd output1 N/A N/A
Security Failure DFS1292 DFS12921 DFS12921 N/A N/A
Segment greater than 32 K DFS12945 DFS12945 N/A N/A
Table 2. Transaction sockets: client message protocol sequence for IMS DFS messages and IMS command output
Message output to client CM1, Synch level confirm CM1, Synch level none CM0, Synch level confirm CM0, Synch level none
Invalid transaction code DFS064 DFS0641 DFS0641 DFS0641 N/A
Transaction stopped DFS065 DFS0651 DFS0651 DFS0651 N/A
Transaction abended DFS555 DFS5557 DFS5551 DFS5557 N/A
Output DFS2082 DFS20822 DFS20821 No output3 N/A
IMS Command Output Cmd output1 Cmd output1 Cmd output4 N/A
Security Failure DFS1292 DFS12921 DFS12921 DFS12921 N/A
Segment greater than 32 K DFS12945 DFS12945 DFS12976 N/A
Notes:
  1. Does not require an ACK to DFS messages.
  2. Requires both an ACK to DFS messages and a second read to get a deallocate response.
  3. The read to receive the transaction output will time out. No data will be received. OTMA treats commit mode=0 and Synch level=Confirm as asynchronous output. If the IMS Host application does not return a message (ISRT to IOPCB), OTMA does not send a deallocate. The TIMEOUT= value specified in the IMS Connect configuration file will have to expire before the disconnect is complete.
  4. Requires an ACK to command output. A second read is not required to get a deallocate response. The command output gets treated as asynchronous output.
  5. Does not require ACK to DFS1294 output. A second receive is required to receive the DFS555 message.
  6. Client will receive DFS1297 rather than DFS1294. The DFS1294 message does not require an ACK. No DFS555 message gets sent, so a second receive is not required. The application is committed, and the application output gets discarded because the segment is larger than 32 K.
  7. Does not require an ACK to DFS messages.

Reason codes for commit mode=1, synch level=confirm

For CM1, there are three reason codes associated with a zero (0) return code, and two reason codes associated with an X'04' return code, which provide information to the client application. The sample flows illustrate how each of these codes are used. The code meanings are listed in the following table.

Table 3. Information reason codes for CM1, synch level=confirm
Return code Reason code Description
X'00' 94 Response - only output from host from non-conversation
X'00' 95 Conversation - last output from host from on conversation
X'00' 96 Conversation/response - middle of conversation
X'04' 97 Deallocate commit - successful completion of host application
X'04' 98 Deallocate abort - abnormal termination of host application