OTMA resynchronization protocol

IMS keeps track of the send and receive numbers in the tpipe structure. The send and receive numbers are updated for each input and output message. When resynch occurs, both the client and IMS share their send and receive numbers to verify that both sides are synchronized. The REQresynch command from IMS releases the send and receive numbers from IMS. The client accepts the numbers and does a comparison to the client's send and receive numbers. If the send and receive numbers are not the same, then the client specifies an action to IMS with the REPresynch command. If both sides have the same send and receive numbers, then the resynch completes successfully. If resynch fails, then the failing tpipe is identified and is not used.

Command message exchange for resynchronization must follow the OTMA resynchronization protocol. Normally, the sequence of events that occurs during resynchronization is:

1. The client issues CBresynch when the client attempts to resynchronize with IMS.
2. IMS sends an ACK to acknowledge receipt of CBresynch. From this point on, IMS quiesces any non-resynch type of input or output for all synchronized tpipes. If IMS receives input while resynchronization is in progress for a synchronized transaction pipe (tpipe), the input is rejected with sense code X'0025'.
3. IMS builds the SRVresynch command and sends it to the client. The SRVresynch command lists all synchronized tpipe names of which IMS is aware for that client.
4. The client receives the SRVresynch command and issues an ACK or NAK message to IMS.
5. If IMS receives an ACK message, IMS begins the resynchronization process for each tpipe. IMS sends the REQresynch command that contains the tpipe name, the IMS recoverable send-sequence number for the tpipe, and the IMS recoverable receive-sequence number for the tpipe.

   If IMS receives a NAK message from the SRVresynch command, IMS sends the DFS2393 message to the MTO and waits for a client-bid request or a CBresynch command from the client.

6. The client receives the REQresynch request. By comparing the information from the REQresynch request with its own information of the tpipe, the client sends the REPresynch reply to IMS and informs IMS about the tpipe
7. IMS receives the REPresynch reply and takes actions on the tpipe, based on the information from the client. IMS sends an ACK message to the client after it has taken actions dictated by the client. IMS enables the tpipe to handle input and output. If IMS cannot perform what the client has requested, IMS stops the tpipe and sends a NAK message to the client.
8. If more than one tpipe exists, the resynchronization process is repeated in parallel for each tpipe. Other tpipes that are not included in the SRVresynch request can send output in either direction anytime after the client receives the SRVresynch command.

The following figure illustrates the flow of nondeferred resynchronization. Following the figure is a sequential list that provides high-level flow description.

1. Client-bid request with resynchronization
2. ACK message
3. SRVresynch command
4. ACK message
5. REQresynch command
6. REPresynch command
7. ACK or NAK message

If the client determines that resynchronization must be deferred for a particular tpipe, the sequence of events for that tpipe differs slightly:

In the REPresynch command, the client can set the stop and wait for resynchronization indicator, and can request that IMS defer any input or output while waiting for the TBresynch command from the client. Assuming steps the first four steps have completed, the events following are:

1. IMS sends the REQresynch command that contains the tpipe name, the IMS recoverable send-sequence number and the IMS recoverable receive sequence number.
2. The client receives the REQresynch request. However, due to any product-specific reasons, the client defers resynchronization for this tpipe by sending the REPresynch command with the stop and wait for TBresynch indicator on.
3. IMS sends an ACK message to acknowledge receipt of the REPresynch command and waits for TBresynch. Meanwhile, IMS quiesces input and output for the tpipe. If IMS receives any input while waiting for TBresynch, IMS sends a NAK message to the client with sense code X'0025'.
4. The client sends the TBresynch command and requests IMS to resume resynchronization for this tpipe.
5. IMS sends the REQresynch command that contains the tpipe name, the IMS recoverable send-sequence number, and the IMS recoverable receive-sequence number. If the associated tpipe cannot be located using the client's TBresynch command, the client receives a NAK message with sense code X'0025'.
6. The client receives the REQresynch request. By comparing the information from REQresynch request with its own information about the tpipe, the client sends the REPresynch reply to IMS and informs IMS about the tpipe.
7. IMS receives the REPresynch reply and takes actions on the tpipe, based on what the client has requested. IMS sends an ACK message to the client if it has taken actions dictated by the client. Otherwise, IMS sends a NAK message to the client with sense code X'0025' or X'0026'.

The following figure shows the flow of deferred resynchronization. Following the figure is a sequential list that provides high-level flow description.

1. REQresynch command
2. REPresynch command with STOP AND WAIT for TBresynch
3. ACK message
4. TBresynch command
5. REQresynch command
6. REPresynch command
7. ACK or NAK message