Advantages of the OTMA protocol

OTMA treats transactions as data objects that have attributes independent of application-, session-, or transport-layer considerations. OTMA is, in effect, a transaction layer, independent of other layers.

As a unique layer, OTMA offers flexibility, simplicity, and performance that other solutions do not offer. This section outlines the transaction-specific services that OTMA provides the client.

Grouping of transactions using transaction pipes.

Security options (for example, the client can verify security or let the server verify the user ID).

Dynamically-bound flow control and processing. The client can decide how transaction requests and responses are to be processed by the server.

The ability for the client to query the server for transactions that the server supports.

Treating transactions as objects. The client can include any pertinent user data with the transaction, and allow that data to stay with all messages generated by the transaction.

The ability for the client to specify a client token with each transaction to correlate input with output.

The ability for the client to control transaction processing performed by the server, in terms of:
  • The client can set a different level of security than that of the OTMA group to which it belongs.
  • To improve performance, the client can eliminate the security-checking that the server performs on the messages it delivers.
  • Transaction grouping, using the transaction-pipe token.
  • OTMA clients that use synclevel=confirm or synclevel=synchpt can specify the timeout value for send-then-commit messages.

Client routing. An OTMA destination descriptor can be easily coded in the DFSYDTx PROCLIB member to reroute an output message that is inserted to an alternate PCB to any OTMA client or to IMS. Alternatively, an IMS exit routine can coded to reroute output messages that are inserted to an alternate PCB.

Architected command output. The client can use the IMS /DISPLAY TRANSACTION command to query the server's transaction attributes and receive the reply in a structured format. Therefore, the need for automated operator scripting to control processing is reduced.

Unlike APPC, when using message flow through transaction pipes, no concept exists of a session that contains the flow-control parameters for all transactions and associated output data for the session.