Retrying a Failed Task

You can design a process to be restarted automatically if it is terminated because of an error. This effect is achieved by assigning a value to the RESTART task attribute. The value of this task attribute specifies the number of times the process is to be restarted following an error termination. Execution of the restarted process begins with the first statement in the outer block. After each restart, the RESTART task attribute value is reduced by one. When the RESTART value is zero, the next error termination is final.

When the process is restarted, no “EOJ” or “EOT” messages are displayed. Some elements of the process survive the error termination and they are reused. These elements are the PIB, the code segment dictionary, and the base of the process stack. All task attribute values of the original process are retained, including the mix number. In addition, the values of any parameters the process received from its initiator are saved.

However, the values of all objects, including all variables and arrays, declared by the process are lost. These objects must be re-created and reinitialized after the process restarts.

If the process has offspring tasks, they are discontinued with a “PARENT PROCESS TERMINATED” error each time the process has an error termination. However, each time the process is restarted, it can execute the task initiation statements again and create new tasks.

A process that was discontinued by an operator command does not restart, regardless of the value of the RESTART attribute. The RESTART value also does not cause a process to be restarted after a halt/load. (It is true that WFL jobs restart after a halt/load, but this feature is not related to the RESTART task attribute. For information about WFL job restarts, refer to Restarting Jobs and Tasks.)

The RESTART task attribute is primarily useful in situations where the process might be discontinued by a temporary hardware fault or where the process will receive different input data after it restarts. If the process is attempting to do something invalid or contradictory, repeated restarts are not helpful. The process terminates abnormally each time.

If the process includes a statement that assigns a value to RESTART, make sure that the statement is not reexecuted after each restart. If the statement is always reexecuted, then the value of RESTART can never reach zero, and the process restarts infinitely. The following example shows an ALGOL program that would enter such a loop:

100 BEGIN
200 REAL X;
300 MYSELF.RESTART:= 4;
400 X:= X DIV O;
500 END.

The following example shows how the program could be modified so that it would not enter an infinite loop. The SW1 task attribute is used as a flag to indicate whether the process has been executed at least once.

100 BEGIN
200 REAL X;
300 IF NOT MYSELF.SW1 THEN
400 MYSELF.RESTART:= 4;
500 MYSELF.SW1:= TRUE;
600 X:= X DIV 0;
700 END.

In ALGOL or NEWP, you can use the ON statement to prevent an abnormal termination from occurring after a program fault. The ON statement has fewer applications than the RESTART task attribute because it applies only to errors that would otherwise cause the process to be discontinued with HISTORYCAUSE = FAULTCAUSE. However, for these cases, the ON statement provides more flexible error handling than the RESTART task attribute.

For more information about the ON statement, refer to Protecting a Process from Faults earlier in this section.