Guardian Programmer's Guide

Table Of Contents
Communicating With Terminals
Guardian Programmer’s Guide 421922-014
10 - 39
Recovering From Errors: A Sample Program
If an error 210 through 231 occurs, then the operation failed at some indeterminate
point. If reading, you should send a message to the user to reenter the data. Your
application should then try the read operation again.
Recovering From Errors: A Sample Program
The TERM^IO procedure shown in the following example provides a simple way of
handling terminal I/O errors. It divides all errors into those that can be indefinitely
retried and those that should not be indefinitely retried. For indefinitely retryable errors,
the procedure keeps repeating the operation as many times as necessary until the
operation is successful.
For all other errors, the procedure attempts the operation up to five times before giving
up. For simplicity, the procedure retries the operation for errors that never go away on
a retry; it does no harm.
The procedure assumes the following about the process:
The process does not set a timeout and therefore will never receive a timeout error
(error 40).
The process does not enable BREAK mode
If there are any modem connections, no attempt is made to wait for reconnection of
the modem following a permanent modem disconnection
?INSPECT, SYMBOLS, NOCODE
?NOLIST
?SOURCE $TOOLS.ZTOOLD04.ZSYSTAL;
?LIST
! Literals:
LITERAL RETRY^LIMIT = 5;
LITERAL YES = 1;
LITERAL NO = 0;
! Global variables:
INT TERM^NUM;
STRING .SBUFFER;
INT RCOUNT;
STRING .S^PTR;
?NOLIST
?SOURCE $SYSTEM.SYSTEM.EXTDECS0(INITIALIZER,WRITEREADX,
? FILE_GETINFO_,WRITEX,DELAY,
? PROCESS_STOP_);
?LIST
.
.
.