OTMA tpipe support for parallel processing of multiple active RESUME TPIPE requests

By default, OTMA creates tpipes that support only a single active RESUME TPIPE request and queues any additional RESUME TPIPE requests until the active RESUME TPIPE request terminates. Supporting only a single active RESUME TPIPE request provides more control over the order in which the output messages from OTMA are processed.

Enabling support for the parallel processing of multiple active RESUME TPIPE requests can significantly increase the throughput of an OTMA tpipe for output messages, particularly those for synchronous or asynchronous callout requests, and can significantly improve failover protection for OTMA tpipes. Although OTMA sends the output messages in the order in which they are created from the IMS application programs, differences in the performance of both the network connections and the IMS Connect client application programs make predicting the order in which the output is acknowledged and processed unpredictable.

When an OTMA tpipe supports multiple active RESUME TPIPE requests, OTMA clients can pull output messages from the tpipe by using multiple active RESUME TPIPE requests, which the tpipe processes in parallel. If the processing for any one RESUME TPIPE request becomes impaired, OTMA continues to deliver the output messages on the tpipe through the other active RESUME TPIPE requests, which prevents the RESUME TPIPE request, or the tpipe itself, from becoming a bottleneck for output messages from IMS.

OTMA tpipe support for multiple active RESUME TPIPE requests also improves failover protection for OTMA tpipes by eliminating the need to switch to a back up OTMA client if the active OTMA client terminates. When an OTMA tpipe supports multiple active RESUME TPIPE requests from multiple clients, if any one of the OTMA clients fail or lose their connection, the others can continue processing the output from the tpipe without any lapse in processing.

Support for multiple active RESUME TPIPE requests can also decrease the complexity and cost of routing output from multiple IMS application programs through OTMA tpipes to the same final destination. Without the parallel processing of RESUME TPIPE requests, to achieve optimum performance, as well as to avoid a potential bottleneck, the output from the IMS application programs is typically routed through multiple OTMA destination descriptors or OTMA tpipes; however, such a configuration usually requires some combination of unique coding in each IMS application program, in multiple OTMA destination descriptors, and in the OTMA clients. With support for multiple active RESUME TPIPE requests, you can realize similar performance benefits by routing the output from the multiple application programs through a single OTMA destination descriptor and a single OTMA tpipe. Multiple OTMA clients can then retrieve the output by issuing the same RESUME TPIPE requests with the OTMA tpipe name specified as an alternate client ID.

For diagnostic purposes, when support for multiple active RESUME TPIPE requests is enabled, the RESUME TPIPE token can be used to correlate each RESUME TPIPE request with the client that issued it. The RESUME TPIPE token, as well as the ID of any tpipe to which undelivered output is rerouted, can be displayed by issuing the existing commands that support OTMA and IMS Connect.