Retrieval of output on OTMA tpipe hold queues

OTMA uses tpipe hold queues to send output to IMS Connect that must be queued for delivery. To retrieve output from the tpipe hold queue, the IMS Connect client issues a RESUME TPIPE request that specifies the name of the tpipe on which the output messages are queued.

The types of output messages that OTMA sends via the tpipe hold queue include:
  • Synchronous callout messages that IMS application programs send by issuing the DL/I ICAL call.
  • Output, such as asynchronous callout messages, that IMS application programs send by issuing the DL/I ISRT call to an alternate PCB (ALTPCB).
  • CM0 IOPCB output messages for which the receiving OTMA client returned a NAK.
  • Response messages to CM0 SendOnly input.
For CM0 transactions sent by a single client that uses a send and receive interaction, the name of the tpipe is typically the client ID. The output from the CM0 transaction can be retrieved in the following ways:
  • By the original client with the client ID that matches the tpipe name.
  • If the original client terminated, by another client that uses the same client ID that matches the tpipe name.
  • By another client that specifies the tpipe name as an alternate client ID in the RESUME TPIPE request.

For synchronous callout messages, the tpipe name is typically defined in IMS on an OTMA destination descriptor. For asynchronous callout messages, the tpipe name can be defined by either an OTMA destination descriptor or an OTMA routing exit routine. For both types of callout messages, the tpipe name is usually specified as an alternate client ID in the RESUME TPIPE request that retrieves the callout messages. The alternate client ID must match the tpipe name that is specified in the OTMA destination descriptor or in the OTMA routing exit routines.

Tpipe names are also specified as an alternate client ID when a tpipe supports parallel active RESUME TPIPE requests.

Note: Synchronous callout request messages are handled by OTMA and IMS Connect in much the same way as asynchronous output. That is, synchronous callout request messages are retrieved by issuing a RESUME TPIPE call. Many of the same rules and guidelines for retrieving asynchronous output also apply to retrieving synchronous callout request messages. However, for synchronous callout messages, if the RESUME TPIPE call from a client is connected to a different IMS Shared Queue member from the one that initiated and processed the synchronous callout request, the client will not receive the message. Because synchronous callout requests are queued to the tpipe hold queue, they are known only by the IMS that owns the tpipe. Super member function is honored for synchronous callout requests only when multiple IMS Connect clients are connected to the same IMS Shared Queue member.
IMS Connect communicates the presence of asynchronous output to the client from a CM0 output response message in one of the following ways:
  • By returning the flag CSM_AMSG in the CSM_FLG1 field in the CSM (complete status message).
  • By returning the flag RSM_AMSG in the RSM_FLG1 field in the RSM (request status message).

If you do not use IMS Connect to retrieve output from an OTMA tpipe hold queue, your client application does not need to analyze the CSM or the RSM. IMS Connect communicates the presence of asynchronous output regardless of whether a client application requests the asynchronous output.

Use the RESUME TPIPE call to retrieve the asynchronous output from the client. You can retrieve asynchronous output on both persistent and transaction sockets.

Restriction: The IMS TM Resource Adapter supports only the asynchronous option, SINGLE.