Guardian Programmer's Guide

Table Of Contents
Communicating With Processes
Guardian Programmer’s Guide 421922-014
6 - 31
Handling Errors
Handling Errors
For the $RECEIVE file, there are no error conditions for which error recovery should be
attempted, except error 40 (operation timed out).
For a process file opened with a sync depth greater than zero, there are no error
conditions for which error recovery should be retried, except error 40.
For a process file opened with a sync depth of zero, an operation that returns error 201
(path down) should be retried once if the process file is a process pair. An occurrence
of error 201 means that the primary process failed. A reexecution of the call that
returned the error causes communication to occur with the backup process, if any. If
no backup process exists, a second error 201 is returned on reexecution of the call. At
this point, the error can be considered fatal.
Communicating With Processes: Sample
Programs
The sample programs shown here perform the same functions as the key-sequenced
file programming example shown in Section 5, Communicating With Disk Files. Here,
the program has been split into two programs: a requester program that handles input
from and output to a terminal, and a server program that controls access to the
database. The programs communicate through the $RECEIVE file. Figure 6-7 shows
the relationship.
To run the application, you need to create the database file and start the server and
requester processes.
Figure 6-7. Example of a Requester/Server Application
VST039.VSD