recovery block notion in this provision is that second (third, fourth, etc.) executions of the process using the same or different algorithms exist and provide a recovery path from which acceptable results may be generated. If no acceptable results are produced by any of the recovery blocks, the system check stops and other forms of recovery (e.g., roll-back using check-pointed data or roll- forward to a safe processor condition) are invoked. The recovery block is a language construct supporting the incorporation of program redundancy into a fault tolerant program. The syntax of recovery block incorporation may take the form: ensure T by B1 else by B2, else by Bn else error. T denotes the acceptance test, B1 denotes the primary try block, and Bn denotes the alternate try blocks. All the try blocks are designed to produce the same or similar computational results. The T acceptance test is a logical expression representing the criterion for determining the acceptability of the execution results of the try blocks. A try (execution of a try block) is always followed by an acceptance test. In the case of multiple processor system configurations, the capability to implement a distributed recovery block scheme and the ability to then implement nested recovery blocks may improve the fault coverage and performance of the recovery block technique. Another attempt at monitoring the behavior of a system is the use of a watchdog coprocessor. Most embedded processor systems use a hardware watchdog timer to detect halts to processor execution or errors in program control flow which are detected through failure of the software execution to reset the timer within the prescribed period of time. The watchdog timer then forces an unmaskable interrupt or a reset to the processor as a means of error detection. The watchdog coprocessor extends the notion from the simple hardware timer to the use of an additional processor to check the results of primary on-line processor elements. An active watchdog may implement interaction with the o