Capabilities of OTMA

OTMA capabilities include support for IMS applications, IMS and OTMA commands, resource monitoring, and more.

An OTMA client can issue most IMS commands, including both type-1 and type-2 commands, and receive responses as a result of those commands.

You can specify a level of security for each OTMA client individually. Alternatively, you can indicate that no security checking is to be done for its messages, thereby minimizing security-processing overhead.

The OTMA message flow and synchronization point protocols can be modified by an OTMA client for each transaction. In other words, the transaction-processing protocol used is not dependent on the current session.

OTMA can monitor how well IMS is processing incoming transactions and alert the client when the processing ability of the IMS system appears degraded.

OTMA can monitor transactions and cancel them if a specified transaction expiration time is exceeded before they are processed.

You can define a limit to the number of input messages from any one OTMA client that can be waiting at the same time to be processed. This prevents OTMA messages from causing an abend as a result of using too much storage. OTMA issues warning messages as the message count approaches the limit. When the message count reaches the limit, OTMA identifies a message flood condition and rejects any new messages from the OTMA clients until the message count drops or a new limit is set.

You can stop incoming transactions and commands from individual OTMA clients without stopping the connection or affecting any transactions or commands that IMS is already processing.

OTMA supports sending transaction messages from IMS application program running in the dependent regions of a local IMS system across a TCP/IP network to another IMS system for processing. IMS Connect is required to manage the TCP/IP connection.

OTMA also supports callout requests from IMS application programs running in IMS dependent regions. Callout is invoked with the DL/I ICAL call. Callout requests allow IMS application programs to request data or services from servers that are outside of the IMS installation. Depending on whether the callout request is processed synchronously or asynchronously, OTMA support for callout requests differs.

OTMA can route callout messages to IMS Connect and its clients, such as IMS Enterprise Suite SOAP Gateway and IMS TM Resource Adapter, and to IBM® MQ. IMS uses OTMA internally (whether or not OTMA is enabled) to route synchronous program switch requests to IMS applications.

The IMS /DISPLAY TRANSACTION command output is in the form of an OTMA message returned to the client in the application-data section of the message prefix.

OTMA-initiated transactions are identified to z/OS® Workload Manager using the OTMA transaction-pipe name, which identifies the logical connection between IMS and OTMA.

Existing IMS application programs that have previously not been used with OTMA can run without modification and interact with OTMA clients. APPC/IMS application programs that use IMS SETO calls might need some modification.