TASK is a system written at ACL to allow users to compile and run binary programs in a simple and efficient manner. It offers many extra facilities and overcomes most of the failings of the simpler ICL macros for running jobs. It makes the process of getting work through the 1906A much easier. TASK caters for all facets of program running from compilation to the execution of binary programs. It provides a standard system to meet the needs of most users. A full description of the TASK system is available in the 1906A TASK System available on request from ACL. Here, a brief introduction to the system is given.
The conversion of a program, say in FORTRAN, into a binary program that the computer can execute is a two-stage process on the 1906A. The first stage converts the FORTRAN into an intermediate language known as semicompiled and is done by a compiler. A second stage consolidates the semicompiled along with any library routines that are required and is done by the consolidator. Although most users need not be concerned about the stages of a job, it aids the understanding of the output from TASK since this documents the various stages, hence indicating at which stage errors occur.
Consider a simple FORTRAN program (hereafter known as the basic example) to read in two numbers as data, use a subroutine to add them and then output their sum. This could be written as follows:
MASTER ABCD
READ(1,999)I,J
CALL ADD(I,J,K)
WRITE(2,998)K
STOP
999 FORMAT (2I6)
998 FORMAT(1X,I6)
END
SUBROUTINE ADD(L,M,N)
N=L+M
RETURN
END
FINISH
Each segment (master and subroutine) must be terminated by END while the whole program should be terminated by FINISH. The term master is used to define the main routine of a FORTRAN program.
A MOP user would input this program into a file, say FRED, and the data into a file FRED-DAT. To compile, consolidate and run the binary program as a background job, he need only type at his teletype:
TASK FORTRAN,*CR FRED
The TASK system will compile, consolidate and run the job either to completion or until an error is found. Note that the data filename is generated by adding -DAT on to the end of the source filename. This illustrates a feature of TASK in that, in certain instances, it will generate default filenames if a user does not specify one. All default filenames contain a - and are usually generated from the source filename. If the data has to be obtained from a different file, the default can be overridden. For example, if the data was in file DATA, the TASK command would be:
TASK FORTRAN,*CR FRED,#CR DATA
The only limitation on the ordering of parameters is that the first must begin with a letter. Parameters starting with * are used at compilation time and with # at execution time.
A background job, where again the program and data are in files FRED and FRED-DAT, could consist of the deck of cards:
JOB JOBNAME1:NTBE34,JD(JT 30 SECS) TASK FORTRAN,*CR FRED ENDJOB ****
If the user does not wish to use the filestore, it is possible in the background job for the program and data to follow the TASK command. For example:
JOB JOBNAME1,:NTBE34,JD(JT 30 SECS)
TASK FORTRAN,*CR,#CR,ER 2ER
MATER ABCD
........
END
FINISH
2 3
2ER
ENDJOB
****
The line containing the numbers 2 and 3 after the FINISH is the data for the program. Note the absence of a filename with the *CR and #CR parameters. The parameter ER 2ER indicates a label, 2ER, to jump to if an error occurs. This should be used when program and data are being read from the same input as the GEORGE commands. If an error occurs in the compilation, consolidation or running of the program, the job will be abandoned by TASK. If no ER parameter is present, the next line of input will be read as a GEORGE 4 command. In an error situation, this could be part of the program or data. If the ER parameter is present, the TASK system, on an error, will jump out to the specified label (D.1.1).
The background user may make partial use of the filestore for either his program or data by specifying the appropriate file. Thus for a program in the file FRED and data with the job, or data in the file DATA and program with the job, the input would be:
JOB JOBNAME2,:NTBE34,JD(JT 30 SECS)
TASK FORTRAN,*CR FRED,#CR,ER 2ER
2 3
2ER
ENDJOB
****
JOB JOBNAME3,:NTBE34,JD(JT 30 SECS)
TASK FORTRAN,*CR,#CR DATA,ER 2ER
MASTER ABCD
........
END
FINISH
2ER
ENDJOB
****
The ER parameter is again included in case of error and is left out at the user's peril. Note that in the second case, had the #CR parameter been absent, there would have been no source filename from which to generate a data filename. In this case, TASK will use NO-NAME for the source filename so that the default data filename is NO-NAME-DAT.
If in the previous examples the program had not required any data, the #CR parameter would have been omitted. TASK would only attempt to assign a default data file if a file with the correct name existed. TASK assumes the program requires no data if the data file does not exist and the user has not given a #CR parameter.
In all the previous examples, the output from the compilation and the results from the program would be sent via a temporary file to a lineprinter. Users who wish to retain a filestore copy of the program's results may do so by using the parameter #LP. For example:
TASK FORTRAN,*CR FRED,#LP RESULTS
will put the output from the program into the file RESULTS (overwriting any previous contents or creating the file if it does not exist). The output will still be listed on a lineprinter.
In all the previous examples the FORTRAN program has been compiled and the resultant binary program has been run. If the same program needs to be run several times with different data, it is much more efficient to SAVE the binary program in the filestore and then RUN it with each set of data. This cuts out the repeated compilation and consolidation of the program which can be quite time-consuming.
If, in the basic example, the program FRED is to be run with a set of data files (say DATA1, DATA2, DATA3, etc), the first job would be similar to the previous one except that a SAVE parameter would be added:
TASK FORTRAN,*CR FRED,SAVE,#CR DATA1
If compilation was successful, this would SAVE the binary program in the file FRED-BIN, erasing any previous contents, and would then run the binary program as before. To run the program again but with the second set of data, the required TASK command would be:
TASK RUN FRED-BIN,#CR DATA2
If the user had not specified a data file, the default data filename would again be FRED-DAT. The base for the data filename is obtained from the characters preceding -BIN in the filename of the binary program.
If a user simply wants to generate the binary program in a file but not to run it, the inclusion of the parameter NORUN will stop TASK before the program is executed. To compile the file FRED and save it in FRED-BIN:
TASK FORTRAN,*CR FRED,SAVE,NORUN
The background user need not obtain his FORTRAN program from the filestore but can include it as part of the job description file (B.1.3.2). In this case, the default name for the binary program saved would be NO-NAME-BIN. However, it is possible to specify the filename for the binary program as part of the SAVE parameter. For example, the binary program could be saved in the file MYBIN by:
JOB JOBNAME4,:NTBE34,JD(JT 30 SECS)
TASK FORTRAN,*CR,#CR,ER 2ER,SAVE MYBIN
MASTER ABCD
..........
END
FINISH
2 3
2ER
ENDJOB
****
To execute the binary program without using the filestore to hold the data, the input would be:
JOB JOBNAME5,:NTBE34,JD(JT 30 SECS)
TASK RUN MYBIN,#CR,ER 2ER
2 3
2ER
ENDJOB
****
Saving of binary programs in specific named files is, of course, also available for MOP users.
Job scheduling at ACL depends mainly on the time that the job is expected to run (Part I). There are two distinct times that are measured for a job. The first, jobtime, is the total time required for compilation, consolidation and execution of the program. The second is the time required to run the binary program. Thus the difference between jobtime and run time is the time for the compilation and consolidation. If the user does not specify to the contrary, the TASK system defines a maximum jobtime for the job of 120 secs and a maximum run time of 30 secs. If either limit is exceeded the job will be aborted. Different values for the maximum jobtime and run time can be specified by the JT and TI parameters respectively. It is in the user's own interests to keep these settings as small as possible. Allowing 90 secs for compilation and consolidation is quite generous and should be sufficient for quite a large program. If compilation and consolidation are likely to take 100 secs and the binary program will run for 50 secs, the user should input:
TASK FORTRAN,*CR FRED,JT 150,TI 50
The two parameters are, by default, defined in seconds. If TASK is called from a background job, the jobtime should only be specified in the JD parameter (E.3.5.3).
Each use of TASK will usually produce two items of lineprinter output. One is the monitoring file which will list the TASK actions including GEORGE commands issued by TASK. As TASK commences sections of a user's job (for example, starting to compile a program), it notes this in the monitoring file preceded by ###### before issuing the GEORGE commands for that section. If the user is still logged-in at a teletype, similar messages will be printed on the teletype. Thus a user can follow through the processes involved in running a job and ascertain where any failure occurred. The monitoring file also gives a list of the parameters read for that job and any default filenames that TASK has generated (J.3.5).
The second item of output gives the various listings and error messages that the compiler and consolidator have produced together with the lineprinter output from the run of the binary program. TASK adds comments, preceded by ######, concerning the ending of the job. It will indicate the point at which the binary program started to run. All output after this point is produced by the program.
There are several types of error that can occur in a job. Initially there may be errors in the TASK parameters. Such errors are noted in the monitoring file by a line containing the offending parameter preceded by ??????. Compilation errors are noted in the compiler output. The compilation failure is noted in the monitoring file - usually by a FAIL ZZ. Consolidation and binary program run-time errors will be noted in their output. Most run-time errors will be noted in the monitoring file by a HALTED EE. Any other errors, such as files not existing, are detected by GEORGE and noted in the monitoring file. TASK checks for these at intervals and ends the job if a fatal error has occurred.
In all the examples so far, the TASK system has provided a default Program Description Segment (PD) for the FORTRAN program. This contains, amongst other things, the linkage between the internal FORTRAN I/O streams and the external GEORGE channels connecting the program to the filestore. If the user wishes to use different peripherals or channel numbers, he must include a PD segment. The default PD segment added to the basic example is:
PROGRAM(FORT)
INPUT 1,5=CR0
OUTPUT 2,6=LP0
END
The default PD allows reading on FORTRAN streams 1 and 5 from a card reader on GEORGE channel CR0 and writing on FORTRAN streams 2 and 6 to a lineprinter on GEORGE channel LP0. The connection between the GEORGE channel and the filestore was achieved by TASK in the previous examples by the #CR and #LP parameters (the full parameters are #CR0 and #LP0 but, if omitted, the 0 is assumed). A full description is given in Part L.
A user wishing to use channels or peripherals not catered for in the default PD must include his own PD in the program. For each GEORGE channel specified in the PD, there must be a corresponding TASK parameter. If the user does include a PD with his program, the default settings no longer apply and must be included where appropriate. For example, if the basic example is extended to read the data from two different files DATA1 and DATA2, the program in file FRED could be:
PROGRAM(FORT)
INPUT 1=CR0
INPUT 3=CR1
OUTPUT 2=LP0
END
MASTER ABCD
READ(1,999)I
READ(3,999)J
CALL ADD(I,J,K)
WRITE(2,998)K
.........
END
FINISH
In this case the call of TASK would be:
TASK FORTRAN,*CR FRED,#CR0 DATA1 ,#CR1 DATA2
The TASK system also caters for the user wishing to read data from either disc or magnetic tape backing store. Full details are given in the TASK manual.
The TASK system will compile programs written in FORTRAN, ALGOL, PLAN and PLASYD. The particular language is specified in the TASK command. For example:
TASK PLASYD,*CR FRED
The features of TASK apply whatever the language and the binary program from any language can be RUN by TASK.
An optimising FORTRAN compiler (L.3.2) is available on the 1906A and this is used by adding the parameter OPT. The basic example would use the optimising compiler by inputting:
TASK FORTRAN,*CR FRED,OPT
Several of the TASK parameters can be truncated so long as the remaining characters define the parameter uniquely. For example, FORTRAN and ALGOL can be truncated to F and A. However, due to the similarity of PLAN and PLASYD, PLAN cannot be truncated and PLASYD can only be truncated to PLAS. The basic example could be run by:
TASK F,*CR FRED
This facility is especially useful as TASK uses the first three characters of the first parameter to generate a unique jobname when the job is run from a MOP terminal (this is the reason for insisting that the first parameter begins with a letter). For example, if a user had logged in using the command:
LOGIN JIM-MOP,NTBE34
then the TASK command:
TASK FORTRAN,*CR FRED
would run a job named FOR-JIM-MOP. If the user wished to run a second FORTRAN Job, he would normally have to wait until the first job had finished due to the jobname clash. However, by using a truncated form:
TASK FO,*CR PETE
the system would run a job named FO-JIM-MOP. Users are reminded of the requirement to limit the number of background jobs in the machine issued by one user at any particular time.
As PLASYD jobs cannot have the language name truncated sufficiently, it is useful to remember that the language name need not be the first parameter. For example:
TASK TI 30,PLASYD,*CR FRED
would run a job named TI-JIM-MOP.
As mentioned earlier, compilers produce an intermediate language known as semicompiled. Since compilation can be a long process, large programs are often split into modules (for example, one or more FORTRAN segments), compiled separately into semicompiled and then all the semicompiled modules are consolidated together to form a binary program. Routines which are used in several programs are often kept in semicompiled form.
Semicompiled is generated at every compilation and to retain it in the filestore the user must add the parameter COMP to his TASK command. The semicompiled will be stored in a default filename, overwriting any previous contents. In the basic example, if the subroutine ADD is to be used in several programs, it could be stored in semicompiled form rather than recompiling each time. In practice, this decision would only be taken when large sections of programs were involved. Splitting the basic example into two files, FRED and ADD which contain:
MASTER ABCD
READ(1,999)I,J
CALL ADD(I,J,K)
WRITE(2,998)K
STOP
999 FORMAT(2I6)
998 FORMAT(1X,I6)
END
FINISH
SUBROUTINE ADD(L,M,N)
N=L+M
RETURN
END
FINISH
The subroutine ADD could be generated in semicompiled form by:
TASK FORTRAN,*CR ADD,COMP,NOCONS
This will compile the file ADD and put the semicompiled in a file ADD-SEM. The parameter NOCONS stands for no consolidation and causes TASK to stop after the compilation. A different semicompiled filename can be defined explicitly in the COMP parameter. To put the semicompiled in MYSEM would reauire:
TASK FORTRAN,*CR ADD,COMP MYSEM,NOCONS
To compile FRED and then consolidate it with the semicompiled from ADD and run the binary program, the following is required:
TASK FORTRAN,*CR FRED,SEMI ADD-SEM,LINK
The SEMI parameter ensures that TASK includes the semicompiled ADD-SEM at consolidation while LINK is a means of informing the consolidator to include ADD-SEM with the semicompiled from FRED. The binary program would then be run using FRED-DAT for data.
Users may also include semicompiled library routines in a similar manner. Full details are given in the TASK manual.