WFL jobs interrupted by a halt/load are automatically restarted after the halt/load. Execution of the job begins where it left off before the halt/load; if a task was in progress, the task is restarted. Keep the following considerations in mind when writing a WFL job to ensure that it will restart properly after a halt/load.
As a WFL job is executing, information about the job is saved off so the job can be restarted in the event of a halt/load. The process of saving off the job information is called job rollout. When a job rollout is done, the values of integer, real, Boolean, and string variables are saved so that these values can be restored to the correct values when the job is restarted. If a system halt/load occurs while a job is running, the job will be restarted by the MCP at the most recent successful job rollout.
In general, a job rollout is attempted before each task is run. This way, only the task that was executing when the halt/load occurred will have to be restarted. However, there are some restrictions on when a successful job rollout can be accomplished. If any asynchronous tasks are active when a job rollout is attempted, the job rollout cannot be completed and will be skipped. If a job rollout has to be skipped, the job can still be restarted after a halt/load; however, the previous successful job rollout will be retained as the current restart point.
In the following example, if a halt/load occurs when OBJECT/PROG2 is running, the job will be restarted at “job rollout point #2”. Thus, the job will be restarted just prior to the initiation of OBJECT/PROG2.
?BEGIN JOB RESTART/EXAMPLE/1; % job rollout point #1 RUN OBJECT/PROG1; % job rollout point #2 RUN OBJECT/PROG2; % Executing OBJECT/PROG2 when halt/load occurs ?END JOB.
For the asynchronous task case, consider the following example:
?BEGIN JOB RESTART/EXAMPLE/2; % job rollout point #1 PROCESS RUN OBJECT/PROG1; % Note: OBJECT/PROG1 is PROCESSED % job rollout point #2 RUN OBJECT/PROG2; % Both OBJECT/PROG1 and OBJECT/PROG2 % are active when halt/load occurs ?END JOB.
In this example, the job rollout that is attempted at “job rollout point #2” will not be successful (because the task OBJECT/PROG1 is active). “Job rollout point #1” will still be the current restart point. If a halt/load occurs during the execution of OBJECT/PROG2, the job will be restarted at “job rollout point #1”.
A job rollout is attempted before each of the following statements:
-
ALTER
-
ARCHIVE
-
Asynchronous subroutine invocation
-
CHANGE
-
COMPILE
-
COPY
-
LOG
-
MODIFY
-
OPEN
-
PRINT
-
REMOVE
-
RUN
-
START
-
WAIT
If one of the following statements contains an ACCEPT function, a job rollout is attempted before the statement:
-
CASE
-
Assignment statement
-
DO
-
File attribute statement
-
IF
-
Task attribute statement
-
WHILE
A job rollout is also attempted after the WAIT statement. The WAIT statement is the only statement where a job rollout is executed both before and after the statement. This occurs because the WAIT statement is often used to synchronize processed tasks, and attempting the job rollout both before and after the WAIT statement helps to ensure that a successful job rollout is completed.
When waiting for a long task to be completed before initiating a halt/load, it is important to consider that the job rollout is executed by the WFL job after the task is completed. Waiting for the task to go to “End of Task” is not sufficient to ensure that the job rollout is completed. For example:
?BEGIN JOB RESTART/EXAMPLE/3; % job rollout point #1 PROCESS RUN OBJECT/PROG1; % job rollout point #2 (not successful because of active task) WAIT(OK); % job rollout point #3 . . . ?END JOB.
If the intention is to wait until OBJECT/PROG1 is completed before halt loading (so PROG1 will not have to be restarted), it is important to allow “job rollout point #3” to be executed. The job would restart at “job rollout point #1”, which obviously would not be the desired result.
The following example illustrates how to avoid the potential problem by enabling the job rollout to be successfully completed before the possible halt/load:
?BEGIN JOB RESTART/EXAMPLE/4; TASK T1,T2; PROCESS RUN OBJECT/PROG1 [T1] PROCESS RUN OBJECT/PROG2 [T2] WAIT (T1 IS COMPLETED); WAIT (T2 IS COMPLETED) %%% A successful job rollout will be executed here %%% WAIT ("Okay to halt/load now", 60); . . . ?END JOB.
However, the contents of most file or task variables are not saved across a halt/load. They will have the following values:
-
Most of the attributes of file variables are returned to what they were immediately after the original file declaration.
-
Most of the attributes of task variables are set to their system default values. This has the same effect as reinitializing the task variable with the INITIALIZE statement. Any task attribute assignments that occurred prior to the halt/load are not restored, including any that were included in the task variable declaration.
The values of constant identifiers that appear in the job parameter list are saved across a halt/load.