Retrieving output from alternate OTMA tpipe hold queues
Client applications can retrieve the asynchronous output or callout messages from an alternate tpipe hold queue by specifying the name of the alternate tpipe as an alternate client ID a RESUME TPIPE call.
When IMS Connect passes a RESUME TPIPE call that specifies an alternate client ID to OTMA, OTMA returns to the caller any messages that are queued to the tpipe that matches the alternate client ID.
- By IMS TM resource adapter when client IDs are unknown because they are automatically generated at runtime.
- In Sysplex Distributor environments, where client applications typically do not know on which tpipe hold queue their output is queued.
- When a tpipe supports multiple active RESUME TPIPE requests, all of the clients that retrieve output from the tpipe specify the tpipe name as an alternate client ID.
- In callout environments, where the tpipe name is usually defined in IMS by an OTMA destination descriptor or, for asynchronous callout only, an OTMA routing exit. In this case, the callout messages are retrieved by specifying the tpipe name as an alternate client ID.
By using an alternate client ID, the client application programs can retrieve the output through any instance of IMS Connect by specifying the tpipe name in the alternate client ID field of either the IRM or the OTMA header.
When retrieving output by using an alternate client ID, a /DISPLAY TMEMBER TPIPE command displays the alternate client ID instead of the actual ID of the client that submitted the RESUME TPIPE request. Consequently, identifying which client submitted a particular RESUME TPIPE request can be a challenge if you need to diagnose a problem.
However, if the target tpipe supports parallel RESUME TPIPE requests, /DISPLAY TMEMBER TPIPE displays the RESUME TPIPE token, which can then be used to identify the true client ID in the output displayed by the IMS Connect command QUERY IMSCON TYPE(CLIENT).