Sample commit-then-send transaction processing flows

The following figure shows a non-OTMA environment: a secondary logical unit type 2 (SLU 2) device communicates with IMS using VTAM® and IMS device support (DDMs). The transactions are enqueued to the IMS message queues. Transaction output is returned to the SLU 2 device.

Figure 1. Standard SLU 2 transaction flow
Communication begins with SLU2 device, goes through VTAM DDMs, to IMS message queues, where an application program issues get unique, insert, and get unique calls.

The following figure shows the same transaction flow in an OTMA environment. The transaction still comes from a SLU 2 device, but the device communicates with IMS using an OTMA client, through an z/OS® cross-system coupling facility (XCF) group, rather than VTAM.

The figure only shows the input flow, which begins with the SLU 2 device, goes to the OTMA client, through the XCF group, and ends at the OTMA server. The transaction is placed on the message queue, and the application issues get unique, insert, and get unique calls. Output follows the same path, in reverse. Of course, if a client is to send output to the SLU 2 device, the SLU 2 device must be defined to the client, and the client must be able to drive that device.

Figure 2. SLU 2 transaction flow using OTMA
Message flows from SLU2 device to OTMA client in sysplex. Message flows through XCF group, to which other clients are attached, to IMS TM OTMA server. IMS TM also holds message queues, which direct message to application.

It might seem that the OTMA flow is more complex, and for a SLU 2 device, perhaps it is. But you can use OTMA to allow any type of device to communicate with IMS, not just VTAM-supported devices. An OTMA client can also act as a gateway for another network, such as a TCP/IP network.