VTAM request-recovery command
If, during its normal operation, a workstation detects an error condition that does not terminate the session with IMS but does cause the workstation to resynchronize with IMS (for example, diskette failure in the controller or a program check), the application program can initiate message resynchronization.
Initiation of message resynchronization is done by sending the VTAM® request-recovery (RQR) command. IMS responds with a CLEAR command followed by the set-and-test-sequence-numbers (STSN) command. Message resynchronization follows and is the same as that described under Message recovery.
Restriction: Session initiation and resynchronization caused
by an SNA Request-Recovery (RQR) command is not allowed when the node
is in response mode and the response reply message is not yet available
for output; that is, the input response mode transaction is still
queued or in the process of execution. Response-mode transactions
are not recoverable or restartable prior to the application sync point;
therefore, session input acknowledgment does not occur until input
processing is complete.
Four bytes of data can accompany
a SIGNAL command that is sent to IMS.
The first two bytes are system-signal data. The last two bytes are
user data that is ignored by IMS.
The first two bytes are handled as follows, with all other values
being ignored:
- X'0000'
- No specific action is taken. This data can, however, cause IMS to send any available output for operative, unprotected components if the workstation is idle due to a previous exception DR1 or DR2 sent to IMS. This input does not reset the output component protection or display protection.
- X'0001'
- This data is treated as an attention signal that causes IMS to stop sending and to wait for input at the end of the current output message. This type of signal can be used before sending either input or required DR1 or DR2 or exception DR1 or DR2 responses to IMS.