In all the previous examples each TASK activation does a specific action or task and then ends. Facilities exist, however, for several such tasks to be processed in one activation of the macro. This can be of use when the results of one task are required in a subsequent task. For instance, consider in a previous example where program FRED was compiled and the resultant binary program was run with several sets of data. Instead of running two or more jobs, one to generate the binary and process the first data set, and then others to process other data sets, the whole could be combined. If the program was in file FRED, the data in files DATA1, DATA2 and DATA3 the following would achieve the desired result:-
TASK JT 180,FORTRAN,*CR FRED,SAVE,#CR DATA1,ER,TASK RUN FRED-BIN,- #CR DATA2,TASK RUN FRED-BIN,#CR DATA3
Each separate task is sandwiched between either the two instances of the word TASK or TASK and the end of the parameters. Hence the first task consists of:-
TASK JT 180,FORTRAN,*CR FRED,SAVE,#CR DATA1,ER
the second:-
TASK RUN FRED-BIN,#CR DATA2
and the third:-
TASK RUN FRED-BIN,#CR DATA3
Hence a simple rule for multiple tasks is to write the individual TASK calls in a string, separating each by a comma (ie after ER and #CR DATA2 in the examples). There is no connection whatsoever between the parameters of the different tasks except in very special cases and two completely unrelated tasks may be run in the same activation of the macro. The ordering of parameters within a task is irrelevant. One exception to the above rule is the JT parameter which must be present in the first task. This is because the jobtime must be sufficient for all the tasks in that activation and it must also be available to calculate the compilation and consolidation time. Had it been situated in the second or third task then TASK would not find it until TASK had reached that task and had a longer than normal compilation been required, then this would have failed time.
The ER parameter is unique in that it affects the whole macro activation. Should a compilation, consolidation or binary program run-time failure occur, the whole job will be aborted. This is so that if a compilation failure occurs and hence no binary is produced, the other data files will not be RUN, thus saving computer time (and your budget!). If there is a likelihood of a binary run time failure on DATA1 (eg fail time), which would hence abort the whole job, it would be better to split the run of the first data set from the compilation task, for example:-
TASK JT 180,FORTRAN,*CR FRED,SAVE,NORUN,ER,TASK RUN FRED-BIN,- #CR DATA1,TASK RUN FRED-BIN,#CR DATA2,TASK RUN FRED-BIN,#CR DATA3
where now DATA1 is RUN as a separate task. Note the NORUN in the first task to stop the binary program being run.
As must have become obvious from the previous example, TASK can need a large number of parameters. For cases where users frequently have to run the same task or simply as an aid to relieve users of the need to remember the necessary parameters, it is possible to STEER the TASK system from a file. Parameters are input into the file, one per line without the commas (and optionally preceded by "C " - see later) and terminated with either a blank line or ****. For example, the previous example could be done by having a file LAZY containing:-
FORTRAN #CR FRED SAVE NORUN ER TASK RUN FRED-BIN #CR DATA1 TASK RUN FRED-BIN #CR DATA2 TASK RUN FRED-BIN #CR DATA3 ****
and activating TASK by:-
TASK JT 180,STEER LAZY
TASK first reads from the macro parameters, until it reaches the STEER parameter. It then reads down the STEER file, and processes each task as it finds it. Eventually it meets the **** and then carries on looking for parameters in the macro. Hence if the user wished to do the tasks in LAZY plus a RUN with a fourth set of data he could put:-
TASK JT 210,STEER LAZY,TASK RUN FRED-BIN,#CR DATA4
It is important to note the presence of the JT parameter in the TASK activation and the fact that it occurs before the STEER parameter. This is because the first task starts in the macro parameters and extends into the steering file and ends at the parameter TASK RUN FRED-BIN. Hence the JT must come before the STEER parameter. The JT must also be in the macro parameters because it is also accessed by GEORGE which is not able to read it from the STEER file.
In the previous examples of background jobs using TASK, either the program or datafile could be read from the JOB by *CR and #CR parameters. If these parameters are used in a STEER file (ie without a filename), they tell TASK to get either the program or data from the STEER file. For example, consider the file FRED as before but where the user now wishes to include his parameters in the same file as the program. FRED would thus look like:-
C FORTRAN
C *CR
MASTER ABCD
......
END
FINISH
and to compile and execute the binary program as before:-
TASK STEER FRED
TASK will read the parameters FORTRAN and *CR (ignoring the 'C ' prefix) and then stop reading parameters at the blank line and carry on looking in the macro call for further parameters as for a normal STEER file. The difference in this case is that the *CR will be interpreted as read the program from the STEER file and the compiler will commence reading the program at MASTER ABCD. This feature can be invaluable for users who have complex compilations and cannot easily remember the correct parameters. Their inclusion in the program file involves no overhead and is much more efficient than putting them in a separate file.
The 'C ' in front of the parameters is entirely optional but is strongly recommended for the following reason. Should the user wish to use the program file in the normal manner, ie not using the STEER facility, the FORTRAN compiler will read the STEERING information but as they are preceded by a C, they will appear as comments and will thus be ignored. Hence:-
TASK FORTRAN,*CR FRED
will still work.
Note that TASK will look for any further parameters in the macro call, after reading those in the STEER file. Hence any additional parameters may be given in this way. For example in the case of:-
TASK STEER FRED
the datafile would be the default FRED-DAT. If the user had required to use a different file, say DATA1, the following would achieve this:-
TASK STEER FRED,#CR DATA1
Alternatively if the user had wished to SAVE the binary program and not to run it:-
TASK STEER FRED,NORUN,SAVE
would suffice.
It is also possible to set up datafiles in the same manner. For example, a datafile DATA for the binary program FRED-BIN might look like:-
RUN FRED-BIN #CR 2 3
which could be used by
TASK STEER DATA
where 2 3 is the data for FRED-BIN. Note again the blank line to separate the STEER parameters from the data and the #CR being interpreted as read the data from the STEER file.
This facility has one restriction in that in between the parameters being read from the STEER file, and its use as either a program source or data-file, no use must be made of GEORGE channel CR0. Hence it is not possible to STEER a compilation and have data in the STEER file, as the compiler reads the program source down CR0.
TASK is able to drive the consolidator using parameters supplied by the user. This may be following a compilation or a free standing consolidation of semi-compiled files. For example, the user who wished to consolidate the file FRED using his own parameters in file CPAR containing:-
*IN (A) *LIB (B) *LIST ****
would use TASK by:-
TASK FORTRAN,*CR FRED,CONS CPAR
Note that TASK will still assign the FORTRAN library by default. The presence of the CONS parameter overrides the automatic consolidation process and reads parameters from CPAR.
Free standing consolidation of semi-compiled is achieved in a similar manner. If a user had compiled FRED into semi-compiled in FRED-SEM then:-
TASK CONS CPAR,SEMI FRED-SEM,#CR FRED-DAT
would suffice. In this case the consolidator is loaded, and driven by CPAR to consolidate FRED-SEM. The FORTRAN library is again included by default and users who wish to use a different library must include this in a LIB parameter. The #CR parameter is included to get the correct datafile as the default filename would be CPAR-DAT from the CONS parameter.
For free standing consolidation only, the consolidator parameters may be read from a STEER file. For example, if the file SPAR contained:-
CONS SEMI FRED-SEM #CR FRED-DAT *IN (A) *LIB (B) *LIST ****
and the TASK call:-
TASK STEER SPAR
would suffice. This facility cannot be used with compilation since the compiler uses CR0 to read the source program. Note again the blank line to delimit the STEER parameters from those for the consolidator.
In the previous section, user-supplied parameters were given to drive the consolidator. For most cases these can be generated automatically by TASK and the examples in the section on the generation and inclusion of semi-compiled showed its use. The LINK parameter has two other features. When used in a multiple task call the LINK parameter will consolidate all the semi-compiled files in the task it is included in and also all the unnamed semi-compiled workfiles generated by any preceding tasks. This facility is intended mainly for mixed language programming and can be illustrated by the following. Consider a FORTRAN program which called several PLASYD routines, and the user wished to compile both the PLASYD in file SUBS and FORTRAN in file FRED, consolidate them together, and then execute the binary program. The TASK call might be:-
TASK PLASYD,*CR SUBS,NOCONS,ER,TASK FORTRAN,*CR FRED,LINK
The first task would compile the PLASYD and exit after compilation leaving the semi-compiled in a workfile. The second task would compile FRED, and consolidate it along with the PLASYD semi-compiled and the FORTRAN library. Had an error occurred in the PLAN compilation,the whole job would have been aborted. Note that TASK will not pick up a named semi-compiled file from a preceding task. Had the user wished to retain the PLAN semi-compiled in a file he would have to name this in the second task, eg:-
TASK PLASYD,*CR SUBS,NOCONS,ER,COMP,TASK FORTRAN,*CR FRED,LINK,- SEMI SUBS-SEM
The parameter COMP puts the semi-compiled in SUBS-SEM and the SEMI SUBS-SEM is picked up by LINK and included in the consolidation.
If the PLASYD program had required library routines, then the library would have to be included in the second task, since only the FORTRAN library is automatically included. Thus the TASK call might be:-
TASK PLASYD,*CR SUBS,NOCONS,ER,TASK FORTRAN,*CR FRED,- LINK,LIB (26,SUBGROUPS-RS)
where (26,SUBGROUPS-RS) is the exofile containing the PLASYD library. It is important to note the order of the LINK and LIB parameters since these dictate the order in which the semi-compiled is consolidated. Workfiles are added to the semi-compiled list when the LINK parameter is encountered, thus if LINK had followed the LIB parameter then the library would have been scanned before the semi-compiled workfile had been accessed and hence the calls for the PLASYD library routines would have been generated after the PLASYD library routines had been scanned.
For users developing large programs it is usual to split the program into modules and hold these in separate files. It is very inefficient to recompile all the modules when a change is only made to one module and much more efficient to hold each module in semi-compiled form, recompile the one with the change and reconsolidate the whole to form a new binary program. This is catered for in TASK by a user having a file containing the names of the semi-compiled to be consolidated together and using this in the LINK system. For example, consider a user having a large FORTRAN program in file MOD1, MOD2, MOD3. Each module has been compiled and the semi-compiled is held in MOD1-SEM, MOD2-SEM, MOD3-SEM. The user also has a file called, say MODLINK which contains:-
SEMI MOD1-SEM SEMI MOD2-SEM SEMI MOD3-SEM ****
He now changes MOD2 and wishes to compile this and consolidate it with the other modules into a new binary program and this is achieved by:-
TASK FORTRAN,*CR MOD2,COMP,LINK MODLINK,SAVE MODBIN,NORUN
TASK first recompiles MOD2 and the COMP parameter tells it to put the semi-compiled in MOD2-SEM, (overwriting the previous contents). On successful compilation the consolidator is driven in the normal manner by the LINK parameter, the parameters read from file MODLINK being treated as if they had been read from the macro call (in an identical manner to the STEER system). Note that the semi-compiled in MOD2-SEM. is consolidated at its position in the list of SEMI parameters (and not first), because the SEMI filename is the same as the default filename generated by the COMP parameter. The binary program is saved to MODBIN for testing later.
Changes to other modules are achieved in an identical manner.
Since the file MODLINK is used in exactly the same way as a STEER file, other parameters can also be put in it. Hence the user could have MODLINK containing:-
SEMI MOD1-SEM SEMI MOD2-SEM SEMI MOD3-SEM COMP SAVE MODBIN NORUN ****
and to recompiled say MOD3 and generate a new binary program in MODBIN:-
TASK FORTRAN,*CR MOD3,LINK MODLINK
Under the paged environment of George 4 it should not be necessary to use overlaying but for those users who must overlay programs (eg because of lower data problems in FORTRAN), TASK can consolidate such programs if the parameter OVERLAY is given, and it will output the binary to the default or specified filename as in the SAVE parameter. Users should note that a Program Description must be given and it must include a DUMP ON statement and an OVERLAY PROGRAM instead of the previous PROGRAM Statement. After consolidation, TASK will carry on and run the binary unless a NORUN is present. Thus an overlay program FRED might look like this:-
DUMP ON OVERLAY PROGRAM (FRED) OVERLAY (1,1) S1 OVERLAY (1,2) S2,S3 INPUT 1 = CR0 OUTPUT 2 = LP0 END MASTER ABCD ..... END SUBROUTINE S1 ... END ... SUBROUTINE S2 ... END SUBROUTINE S3 ... END FINISH
where subroutines S2 and S3 are to be overlayed onto the area occupied by subroutine S1.
To compile, consolidate and run this program with data from FRED-DAT, the call would be:-
TASK FORTRAN,*CR FRED,OVERLAY
and the overlay binary would be put in FRED-BIN, overwriting any previous contents.
Consolidation of overlay programs may also be done by the LINK system and users of large overlay programs are recommended to use the previously described system of semi-compiled.modules. If in the illustration of that system, MOD1, MOD2 and MOD3 now hold an overlay program then replacement of SAVE by OVERLAY is all that is needed to make the examples work.
TASK contains several other facilities some of which are briefly outlined below.
The *LP parameter diverts all LP0 output from the compilers, consolidation and if no #LP parameter is present the run of the binary program, to the monitoring file. If the *LP is followed by a filename, that is used for output purposes. The output is still listed to the lineprinters.
The MON parameter is available to users who wish to return their monitoring file in the filestore. On its own, it uses a default filename, eg FRED-MON and when followed by a filename, it uses that. The monitoring file is still listed to the lineprinters.
The KEEP parameter is intended for remote users and retains the monitoring file, and all LP0 output in the filestore as well as listing them to the lineprinters. These are normally put into default filenames, eg FRED-OUT for compiler output, FRED-RES for binary program results and FRED-MON for monitoring files unless the user specifies otherwise by appropriate parameters *LP, #LP or MON which will override the defaults.
The parameter NOLIST suppresses all listing of output to the lineprinters.
The parameter PR string allows the LP0 output and monitor file to be listed to a lineprinter having the property string. This enables remote MOP users to send output to a nearby RJE (Remote Job Entry Station -either an ICL 7020 or GE 2050). It applies to all the output for that call of TASK. Thus a user could do
TASK FORTRAN,*CR FRED, PR GLASGOW
to get his output back to the RJE Station having the property GLASGOW.
To obtain a different default filename the parameter DEFAULT may be used followed by the new default base. This should not be greater than eight characters long. For example, DEFAULT JIM gives default filenames with a base of JIM, ie JIM-DAT, JIM-SEM, etc.
Programs may be read from paper tape files by using the *TR parameter in place of *CR and files in EBCDIC and ATLAS codes may also be used by following *CR by the appropriate code in slashes, for example:-
*CR/EBCDIC/ FRED or *CR/ATLAS/ FRED
Note that only the first character (E or A) in the /.../ is significant.
For very large FORTRAN compilations where the compiler fails illegal reservation violation and has to have its virtual core expanded, it is much more efficient to do this before compilation starts. This is achieved by the MZ parameter which is followed by the new size of the virtual core required. For example, if FRED needed 120,000 words to be compiled in:~
TASK FORTRAN,*CR FRED,MZ 120000
would suffice. Note that MZ must be followed by a number and must be in the macro call as, like the JT parameter, it is accessed by GEORGE.
The *?? parameter provides the same facilities as #?? but at compilation or a stand alone consolidation.
The BIN parameter allows users to generate standard 1900 format direct access binary programs and requires the DUMP ON Program Description Statement to be present.
DENSE allows a sparse program to be consolidated dense when using the LINK system.
The parameters for a single task may be put inside brackets to overcome the limitation on 15 parameters for the macro. These must not include any parameters GEORGE accesses eg JT, MZ or MEDIA.