Sample OTMA resynchronization message flow
The following figure shows the flow of messages through a synchronized transaction pipe.
Receive- and send-sequence numbers for each side (IMS and client) are represented by the letters R and S, which are set in the message-control information section of the message prefix. These numbers apply to the entire message (including multi-segment messages). R and S are not necessarily related.

- 1 After the client submits the transaction, IMS enqueues the transaction, and the transaction runs. The receive-sequence number is incremented by 1.
- 2 IMS sends the client an ACK message to acknowledge receiving and enqueuing the transaction.
- 3 IMS enqueues the output and sends the data to the client.
- 4 The client sends an ACK message
to IMS to acknowledge receiving
the output; however, IMS never
receives this ACK to message 15 because of an IMS failure.
Resynchronization proceeds as follows:
- 5 The client sends a client-bid request to IMS to initiate resynchronization.
- 6 IMS sends an ACK message to the client that resynchronization will begin.
- 7 IMS sends the SRVresynch command to the client to begin resynchronization.
- 8 The client sends an ACK message to IMS to acknowledge receiving the SRVresynch command.
- 9 IMS sends the REQresynch command to the client to update the receive- and send-sequence numbers to (9,14).
- 10 The client sends the REPresynch command to IMS to update the receive- and send-sequence numbers to (15,9), and to tell IMS to dequeue the last output message. IMS dequeues message 15 and updates S to 15.
- 11 IMS sends an ACK message to the client.