6100 ADCCP Programming Manual

Appendix A File -System Error Codes
069225 Tandem Computers Incorporated A–1
This appendix describes failure recovery strategies and lists the file-system error codes
pertaining to CP6100 or to the 3650/6100 family controllers. The error number, a brief
description of the error, what caused it, and a corrective action that you can take are
given for each error code.
Errors listed in table A-1 indicate that something was wrong with the request or the
device. The description briefly suggests what to do for each kind of error.
Errors listed Table A-2 indicate temporary resource shortages or path-switch
conditions. For temporary resource shortage, the request will probably work if you
repeat it.
Recovery Strategies In your application, you will need to consider how to recover from path switches and
subsystem, LIU, or power failures. This subsection describes some possible strategies
for recovering from these types of failures.
Path Switches Recovery from a path switch is more complex than recovery from device failures or
resource shortages. A path switch may leave the line state undefined. (In ADCCP, a
path switch does not change the state of the line. You can retry your request without
loss or duplication of data.) If your application retries writing to the line, it may be
sending text for the second time. If your application retries reading from the line, it
may not get the data you were expecting. For example, data arrives and is
acknowledged, but a failure occurs before the data is delivered to your application
buffer. In this case, repeating a read causes the remote station to send the next block
or message rather than the one that was lost because the remote station has already
received an acknowledgment for the lost data.
To handle a situation as described above, you can use end-to-end recovery. End-to-
end recovery is a strategy where you backtrack to the most recent point where you
knew what was happening. Here are three cases to illustrate the end-to-end-recovery
strategy:
Case 1 Your application was transmitting data when the error occurred. The normal
way to handle this is to repeat the last transmission, somehow signaling the
other station to discard any duplicate data. If a path switch changes the state
of the line in the protocol you are using, you may need to make another
request to restore the line state.
Case 2 Your application was receiving data when the error occurred. The normal
way to handle this 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 will probably need 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 are using, you may need to
make another request to restore the line state.