6100 BSC Programming Manual

File System Error Codes
The theoretical strategy for recovery is simple: backtrack to
the most recent point where you knew what was going on. Here are
some scenarios to illustrate the strategy:
Case 1: You were transmitting data when the error occurred.
The normal way to handle this case is to repeat the last
transmission, somehow signalling the other station to discard any
duplicate data. If a path switch changes the state of the line
in the protocol you're using, you may have to make another
request to restore the line state.
Case 2: You were receiving data when the error occurred.
The normal way to handle this case is to abort the data transfer
and start over, unless the device understands an order to repeat
its last transmission (or to repeat transmission from a given
point). If the application gets its data from terminals, you'll
probably have to write a message on the appropriate terminal,
asking its user to type or submit the data again. If a path
switch changes the state of the line in the protocol you're
using, you may have to make another request to restore the line
state.
Case 3: You were establishing or severing a connection when
the error occurred.
The best way to handle a mode-setting, line bidding, or
connection sequence is to abort the sequence and start again from
the beginning.
In some protocols, you might have to try your first WRITEREAD
several times, until the line is in a state in which the protocol
can accept the request. For example, if the failure occurred
while the protocol was waiting to read, it might still be
watching the line for data when you retry; in that case, you'll
get a message like "wrong line state for this operation," and
you'll have to keep trying until the earlier read operation times
out. In some protocols, you send other requests to ensure the
line state before you retry: in BSC, you typically abort the
request, send an EOT sequence, and then retry (as described in
the 6100 BSC Programming Manual).
A-2