OTMA IMS-to-IMS TCP/IP communications flow

An IMS application program that is running locally in an IMS dependent region can send transaction messages across a TCP/IP network to a remote IMS system for processing.

The flow of a transaction message that is sent to another IMS system across a TCP/IP network is illustrated by the following steps.

1. An IMS application program that is running in the local IMS system issues a CHNG call with the name of an OTMA destination descriptor specified as the destination for the transaction message and then issues an ISRT ALTPCB call to send the transaction message. As an alternative, instead of using an OTMA destination descriptor, you can use an OTMA User Data Formatting exit routine (DFSYDRU0) in the local IMS system to route ALTPCB output to remote IMS systems.
2. IMS routes the transaction message to a local IMS Connect instance based on the information specified in the OTMA destination descriptor. If a super member group is active locally, IMS distributes output transactions to up to 8 IMS Connect instances in the super member group by using a round-robin algorithm.
3. Using commit-then-send (CM0) and a send-only with acknowledgment protocol, IMS Connect sends the transaction message to a remote IMS Connect instance on a TCP/IP connection that is identified by a client ID generated by the local IMS Connect instance.
4. The remote IMS Connect instance sends the message to OTMA in the remote IMS system.
5. In the remote IMS system, OTMA returns an acknowledgement (ACK) to IMS Connect and queues the message as an IMS transaction.
6. An IMS application program running in the remote IMS system processes the transaction.
7. Any output generated by the IMS application program in the remote IMS system is queued to the tpipe hold queue

The following figure illustrates the flow.

Figure 1. IMS-to-IMS TCP/IP communications flow for an OTMA transaction message