Guardian Programmer's Guide

Fault-Tolerant Programming in C
Guardian Programmer’s Guide — 421922-014
27 - 28
Run-Time Considerations
•
The crtlnsh header file contains the declarations that support active backup
programming. (The functions that support fault-tolerant programming are
implemented in pTAL. By using the crtlnsh header, the appropriate TAL
interface code is generated.) Functions declared in the crtlnsh header are
defined in the crtlns library file.
•
HP provides two different file-reference models: the ANSI model and the alternate
model. Only the ANSI model supports fault-tolerant file operations (for example,
open with sync depth, backup open, get file state, and so on).
•
EDIT files do not support fault-tolerant file operations. Therefore, the
ANSISTREAMS pragma must be specified for compilation of the main function so
that the standard files will be opened as ANSI files (code 180 files) instead of EDIT
files.
•
Active backup C programs can include pTAL code, but the pTAL components of an
application cannot use passive backup programming techniques. Other mixed-
language programming is not allowed.
•
An active backup program must run in the Common Run-Time Environment (CRE).
•
An active backup program can run only as a Guardian process; it cannot run as an
OSS process.
Run-Time Considerations
Run-time issues are:
•
An active backup program can use the full range of memory management facilities;
no special support is needed. The primary and backup processes never need to
have the same memory state, and each process manages its memory
independently.
•
The standard C files (stdin, stdout, and stderr) are automatically backup
opened (in the backup process). Any other files on which fault-tolerant operations
will be performed must be explicitly backup opened by the __ns_backup_open
function.
•
Errors detected in the backup process are not automatically communicated to the
primary process; user code must be written to handle such processing.