Auto message control

When using the auto message control option (by setting field IRM_F5 to IRM_F5_AUTO), the client can receive all of the messages on the OTMA Asynchronous Queue, and any messages that are placed on the OTMA Asynchronous Queue after the current messages are all removed.

Using the auto message control option will force the following sequence of events to occur:

  1. Client issues CONNECT function.
  2. Client issues RESUME TPIPE call.
  3. Client issues RECEIVE function to receive the asynchronous output.
  4. Client sends ACK message to IMS Connect.
  5. Client repeats events three and four.

If all messages have been removed from the queue, event three will remain active (that is, in receive state) until the user-specified timer supplied in the IRM has expired. IMS Connect will then terminate the socket, unless the socket is persistent.

Recommendation: If event three or event five receives a disconnect of the socket, the client should disconnect and then wait for a time interval before repeating events one through five.
Using the auto message control option, the client can always terminate a non-persistent socket connection in either one of the following ways:
  • Respond to the output message with a NAK response
  • Send a DEALLOCATE request rather than an ACK response

The message being processed is put back on the IMS output queue, and IMS Connect terminates the socket, unless the socket is persistent.

If the client responds with an ACK message, then issues a DISCONNECT, the connection is only terminated between the client and TCP/IP; the client remains in a CONN state with IMS Connect. When IMS Connect attempts to send the next asynchronous output message, IMS Connect is notified that the connection has been lost. IMS Connect does not acknowledge (NAK) OTMA, and the message is put back on the IMS output queue. IMS Connect then terminates the socket. If the client issues an ACK message and then issues a DISCONNECT, followed by a connect and transmittal of data, IMS Connect responds with a duplicate client ID error and disconnects the socket connection.

If the client responds with a NAK message rather than an ACK in events three or five, the message that received the NAK message is put back on the OTMA asynchronous hold queue, IMS Connect terminates the socket, and the messages can be retrieved later.

Note: The IMS Connect AUTO support is based on the premise that the socket connection is dedicated as an output-only device. Combining RESUME TPIPE calls (with auto asynch option specified) with transactions on the same socket connection or SENDONLY on a persistent socket, can yield unpredictable results. If you want to change from RESUME TPIPE auto option mode to a mode that will allow for transaction processing, you must change the auto asynch option by performing one of the following options:
  1. NAK one of the RESUME TPIPE outputs. This will change the asynch mode from auto to noauto. To return to auto mode, a RESUME TPIPE call with auto must be specified.
  2. On a timeout notification associated with the RESUME TPIPE AUTO, the client application can disconnect, reconnect, and issue a RESUME TPIPE call with single, single with wait, noauto, or nooption with a very short IRM_TIMER value. The IRM_TIMER value should be small, so that a timeout notification can be returned immediately. Issuing a RESUME TPIPE call with one of the four asynch mode options, changes the mode from auto to one of the specified options. After the RESUME TPIPE call is issued and a timeout notification is returned, the client application can send in a transaction.
  3. On a timeout notification associated with the RESUME TPIPE AUTO, the client application can disconnect, reconnect, and issue a RESUME TPIPE call with single, single with wait, noauto, or nooption with any valid IRM_TIMER value. Upon receiving an output message, send an ACK with IRM_TIMER set to nowait or a valid value. If the IRM_TIMER value is set to nowait, the client can then send in a transaction. If the IRM_TIMER is set to a valid value, after receiving the timeout notification, the client application can then send in a transaction.