When a task variable is to be reused for another task, the task variable should normally be reinitialized first. Otherwise, the task variable retains the task attribute values that were associated with the previous task, and these can sometimes cause undesirable side effects.

Examples

The following examples show some of the possible side effects of reusing task variables without reinitializing them.

The following example runs SYSTEM/CARDLINE twice:

?BEGIN JOB TASK/TEST; 
   TASK T; 
   RUN SYSTEM/CARDLINE[T]; 
     FILE CARD (KIND=DISK,TITLE=INPUT1); 
     FILE LINE (KIND=DISK, PROTECTION=SAVE); 
   RUN SYSTEM/CARDLINE[T]; 
     FILE CARD (KIND=DISK,TITLE=INPUT2); 
?END JOB. 

This program takes an input file named CARD and produces an output file named LINE, which by default is a printer file.

The first time SYSTEM/CARDLINE is run, the file LINE is file-equated to have a KIND of DISK, and the output is thus sent to a disk file. This file equation is also associated with the task variable T. When SYSTEM/CARDLINE is run the second time, no file equation for the file LINE is explicitly included, but the file equation is passed on by task variable T, and the output is still sent to a disk file.

In the following example, T is the declared task used for two RUN statements. In the second RUN statement, the PRIORITY information, file equation information, and setting of the OPTION attribute are still in effect when Y is executed. When T is re-used, less obvious side effects might also occur. For example, if X changes its TASKVALUE, that TASKVALUE would still be in effect when Y is executed, which might cause undesirable side effects on Y.

?BEGIN JOB EXAMPLE1; 
   TASK T; 
   T(PRIORITY=50); 
   RUN X[T]; 
      FILE F(KIND=DISK); 
   T(OPTION=(FAULT)); 
   RUN Y[T]; 
?END JOB.

The following example includes two COMPILE and GO statements that both have the same task variable [T] associated with them. The task variable T has PRIORITY=50 assigned to it; this priority is applied to the GO part of both compiles.

File equations made to the first COMPILE statement also affect the second COMPILE statement, because the task variable retains the file equations. Because of this fact, the COMPILER FILE CARD equation after the first COMPILE statement has the (probably unintentional) effect of causing the second COMPILE to also read from the disk file named INPUT.

Both COMPILE statements are followed by file equations that affect the same file F; in this case, the first COMPILE statement treats F as a disk file, and the second COMPILE statement treats F as a remote file:

?BEGIN JOB EXAMPLE2; 
   TASK T; 
   T(PRIORITY=50); 
   COMPILE OBJECT/XDISK [T] WITH ALGOL GO; 
      COMPILER FILE CARD(KIND=DISK, TITLE=INPUT); 
      FILE F(KIND=DISK); 
   COMPILE OBJECT/XREM [T] WITH ALGOL GO; 
      FILE F(KIND=REMOTE); 
?END JOB. 

The following example illustrates how the INITIALIZE statement can be used to prevent the attribute values of one task from being accidentally assigned to the next task:

?BEGIN JOB EXAMPLE3; 
   TASK T; 
   T(PRIORITY=50); 
   RUN X[T]; 
      FILE F(KIND=DISK); 
   INITIALIZE(T); 
   T(OPTION=(FAULT)); 
   RUN Y[T]; 
?END JOB. 

The task variable T is reinitialized, after which the PRIORITY information and the previous file equation information are no longer in effect. Thus, program Y runs with the FAULT option set, but with no other task or file equations.