DFS4830I OTMA ENDED RESUME TPIPE FOR TMEMBER/TPIPE xxxx/yyyy RT= zzzz
Explanation
This message is issued for one of the following reasons:
While OTMA was waiting for an ACK or NAK from the OTMA target member (tmember or client) xxxx with the transaction pipe (tpipe) yyyy, a CM0 timeout action or an IMS command such as /STOP TMEMBER TPIPE canceled the wait for an ACK or NAK and ended a resume tpipe request from the target member. IMS also sends out the protocol message "cancel resume output for tpipe hold queue request protocol command" to the target member.
When the DL/I ICAL call has a large amount of request data (greater than 32000 bytes) with a small timeout value, it is likely to trigger the timeout action. This message was issued and the resume tpipe request was canceled.
Explanation
In the message text:- xxxx
- Name of the OTMA client.
- yyyy
- Name of the tpipe.
- zzzz
- Resume tpipe token set by the OTMA client (such as IMS Connect).
System action
Processing continues.Operator response
Identify the cause of the missing ACK or NAK for the resume tpipe request. The cause might be an application program or a failure in the network component.Programmer response
The programmer response can be one of the following:
Ensure that your program issues an ACK or NAK to IMS for the received CM0 output message. Also, it is possible that the ACK or NAK cannot arrive at IMS OTMA because of a network failure. You can submit multiple resume tpipe requests to IMS. When one ends, the other can continue to retrieve messages from IMS.
A system delay in IMS might slow down the ICAL processing. Increase the DL/I ICAL call timeout value by changing the AIBRSFLD value in the ICAL call. If AIBRSFLD is not specified, use the UPDATE OTMADESC command or code the DFSYDTx member of the IMS.PROCLIB data set to increase the timeout value for the ICAL call.
Problem determination
The problem determination can be one of the following:
Examine the network trace to identify which component in the network did not forward the ACK or NAK to IMS. Ensure that your application program issues an ACK or NAK to IMS for the received CM0 output message or synchronous callout message.
Examine the 67D0 log record to find out the root cause.