Network Error Handling Options with Multiple Resilience

The behaviour of applications when all the servers required for a given operation fail is normally controlled by optional command tails specified when AUXDISTR is loaded, and is also dependent on whether or not there is a local database. However programs can change how errors are handling by posting to the network status table. The table below summarises the available error modes, the command tails needed to select them as the default error mode for programs that do not set an explicit error mode for themselves, and the behaviour of the system when they are used.

Error Mode  Command Tails  Behaviour with local database  Behaviour without local database 
0 (none) Application receives sys_fail 7 (Network error), and will terminate unless it contains special error handling. As for system with local database
1 −nocrash Revert to local database only
Updates pending on remote servers at time network problem arose lost
Future updates that should be posted remotely posted to local database
Wait for a server to restart
Updates pending on remote servers at time network problem arose lost
2 −nofail Revert to local database only
Updates pending on remote servers at time network problem arose posted to local database
Future updates that should be posted remotely posted to local database
Wait for a server to restart, Updates pending on remote servers at time network problem arose will be resent when network is restored
3 −nocrash −readlocal Revert to local database for reads
Subsequent updates that would be sent to remote servers are ignored
If read, wait for a server to restart
If update, ignore error
4 (not available) Ignore error, subsequent reads return 'not there'
Subsequent updates are ignored
As for system with local database

If an update is lost or ignored, the next commit will fail.

Error mode 4 cannot be selected as the default using command tails, but is accessible under program control (by posting to the network status table.)

If you use −nocrash or −nofail with −mustuse n you need to be aware that the −mustuse n behaviour will only happen while at least one database server is online. If all servers go offline, so that the system reverts to completely local operation, commits that would normally fail because the "vital" server is offline will succeed.