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 semi-compiled and is done by a compiler. A second stage consolidates the semi-compiled along with any library routines that are required and is done by the consolidator.
Whilst 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 any errors occur.
This section describes how to compile and execute a simple FORTRAN program. A basic knowledge of FORTRAN and the GEORGE 4 filestore is assumed.
Consider a simple program (hereafter known as the basic example) to read in two numbers from a data file, use a subroutine to add them and output their sum. This could look like the following:-
MASTER ABCD
READ(1,999) I, J
CALL ADD(I,J,K)
WRITE(2,998)K
STOP
999 FORMAT(2I0)
998 FORMAT(1X,I6)
END
SUBROUTINE ADD(L,M,N)
N=L+M
RETURN
END
FINISH
Note the END after each segment (master and subroutine) and the FINISH to terminate the whole 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 he types into his MOP console:-
TASK FORTRAN,*CR FRED
TASK will carry out the job either to completion or until an error is found. Note that the data filename is generated by adding -DAT onto 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 was to be obtained from a different file, the default can be overridden, eg:-
TASK FORTRAN,*CR FRED,#CR DATA
where the data is now in file DATA.
Note that in this and, unless specified, in all other cases the ordering of parameters is not significant. The only limitation is that the first parameter must begin with a letter.
A background job where again the program and data are in files FRED and FRED-DAT would consist of the deck of cards:-
JOB JOBNAME,:USERNAME TASK FORTRAN,*CR FRED EJ ****
For the background job where the user does not wish to use the filestore the program and data may follow the TASK macro call, eg:-
JOB
JOBNAME1,:USERNAME
TASK FORTRAN,*CR,#CR, ER 1ER
MASTER ABCD
.....
END
FINISH
2 3
1ER
EJ
****
The line 2 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 1ER is a notification to TASK of what to do if an error is found and will cause a jump to label 1ER after the program and data. If this parameter is omitted and an error is found the data and possibly the program may be read by GEORGE with disastrous results.
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 with data in the job a background job could be:-
JOB JOBNAME2,:USERNAME TASK FORTRAN,*CR FRED,#CR,ER 1ER 2 3 1ER EJ ****
and for the data in file DATA and the program in the job:-
JOB JOBNAME3,:USERNAME
TASK FORTRAN,*CR,#CR DATA,ER 1ER
MASTER ABCD
.....
END
FINISH
1ER
EJ
****
The ER parameter is again included in case of error and is optional at the user's peril. Note that in the second case had the #CR parameter been absent there would have been no source filename to generate a data filename from. TASK will use NO-NAME in this case and generate a default data filename of 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 the file existed. TASK assumes the binary requires no data if the datafile 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 would go via a workfile to the lineprinters. Users who wish to have a filestore copy of the binary program's results may do so by using the parameter #LP, for example:-
TASK FORTRAN,*CR FRED,#LP RESULTS
would put the LP0 output from the binary program into a file RESULTS (overwriting any previous contents or creating the file if it does not exist). The output will still be listed to the lineprinters.
In all the previous examples the FORTRAN has been compiled and the resultant binary program has been run. When the same program needs to be run several times with different data it is much more efficient to SAVE the binary program into the filestore and then RUN it with each set of data. This cuts out the repeated compilation and consolidation of the program which is a very inefficient process.
Consider therefore the original example where the program is now going to be run using several data sets. A MOP user would input the program into a file, say FRED, and the data into a series of files, say DATA1, DATA2, DATA3, etc. The first job would be as before with the addition of the SAVE parameter, for example:-
TASK FORTRAN,*CR FRED,SAVE,#CR DATA1
If compilation was successful this would SAVE the binary program into a file FRED-BIN, erasing any previous contents, and then run the binary program as normal.
Now, to run the binary program with another set of data, say in file DATA2, the MOP user does:-
TASK RUN FRED-BIN,#CR DATA2
If the user had not specified a data file the default filename would again be FRED-DAT, ie the base of the default name is obtained from the characters before the - in FRED-BIN.
Where users want simply to generate the binary but do not wish to run it, the inclusion of the parameter NORUN, will stop TASK at that point, for example:-
TASK FORTRAN,*CR FRED,SAVE,NORUN
will produce a binary program in file FRED-BIN but will not run it.
The background user operates in a similar manner except when he does not get his FORTRAN program from the filestore. In this instance the default name for the binary program would be NO-NAME-BIN unless the user gives his own filename with the SAVE parameter, for example:-
JOB JOBNAME4,:USERNAME
TASK FORTRAN,*CR,#CR,ER 1ER,SAVE MYBIN
MASTER ABCD
......
END
FINISH
2 3
1ER
EJ
****
Here the binary program would be SAVED into file MYBIN, again any previous contents being lost.
To execute the binary program without using the filestore for data, the background user does:-
JOB JOBNAME5,:USERNAME TASK RUN MYBIN,#CR,ER 1ER 2 3 1ER EJ ****
where line 2 3 is the data.
In order to avoid jobs that get into a loop running indefinitely and to aid scheduling, they are given time limits. Two controls are imposed. The execution time of the binary program is set by default at 30 seconds and the total jobtime (total of compilation, consolidation and binary program run times) at 120 seconds. When a user wishes to exceed or reduce either or both these values he must do so via TASK parameters. The critical factor is the difference between the jobtime (JT) and the binary run time (TI) which must be sufficient for the compilation and consolidation time. The current difference (120-30) allows for a fairly large program and users whose compilation and consolidation times exceed this value should increase the difference. For example, if file FRED is small but the binary program must run for 50 seconds, the following should be used:-
TASK FORTRAN,*CR FRED,JT 140,TI 50
If FRED took longer than 90 seconds to compile and consolidate, the jobtime should be increased to cater for this. For example, if the compile and consolidate time is now 100 seconds the following would suffice:-
TASK FORTRAN,*CR FRED,JT 160,TI 50
This results in a difference of 160 - 50 = 110 seconds which gives sufficient time for compilation, consolidation and a little in hand for system overheads.
Each use of TASK will usually produce two items of lineprinter output. One is the monitoring file which is a log of all that TASK did including all the GEORGE commands it issued. As TASK commences each section 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. Thus a user can follow through the processes involved in running a job and ascertain where any failure occurred. Also given in the monitoring file is a list of the parameters read for that job and any default filenames that TASK has generated.
The second item of output gives the various listings and error messages that the compiler and consolidator give, and also the lineprinter output from the binary program. TASK also adds comments about the ending of the job, again preceded by ######, the most usual being when it commences to run the binary program. In this instance all output after that point is from the binary program.
There are several types of error that can occur in a job. One is an error in a TASK parameter and these are indicated in the monitoring file, the offending parameter being shown in a line commencing ??????.
Compilation errors are noted in the compiler output and the compilation failure is noted in the monitoring file, usually by a FAIL ZZ.
Consolidation and binary program run time errors are also noted in their output, with the monitoring file usually having a HALTED EE for the latter.
Any other errors that TASK finds, 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 foregoing examples the TASK system provided a default Program Description (or PD) Segment for the FORTRAN program. This contains amongst other things the linkage between the internal FORTRAN input/output numbers (ie the 2 in WRITE(2,998)K) and the external GEORGE channel connecting the program to the filestore. If the user wishes to use different peripherals or channel numbers he must include a PD segment. Adding the default PD to the basic example the program would look like:-
PROGRAM(FORT)
INPUT 1,5=CR0
OUTPUT 2,6=LP0
END
MASTER ABCD
READ(1, 999)I, J
.....
END
FINISH
Note again the PD segment is terminated by an END. The default PD allows reading on FORTRAN channel numbers 1 and 5 from a card reader on GEORGE channel CR0 and writing on FORTRAN channels 2 and 6 to a lineprinter on GEORGE channel LP0. The connection between the GEORGE channel and the filestore via TASK was achieved in the previous examples by the #CR and #LP parameters. (Note the full parameters are #CR0 and #LP0 but the 0 is assumed if omitted).
As illustrated by the previous examples, TASK will cater for CR0 and LP0 (and list output to the latter on the lineprinter). Thus any other GEORGE channels in the program description (eg CR1,DA0 etc) must have a corresponding TASK parameter (eg #CR1,#DA0 etc).
A user wishing to use channels or peripherals not catered for in the default PD must include his own PD in the program. If he does so the default values do NOT apply and where appropriate must be included in the user's PD. For example, consider the previous example where it is now required to read data from two different files DATA1 and DATA2 and to include the TRACE2 level diagnostics. The program in file FRED could be:-
PROGRAM(FORT)
INPUT 1=CR0
INPUT 3=CR1
OUTPUT 2=LP0
TRACE 2
END
MASTER ABCD
READ(1,999)
1 READ(3,999)J
CALL ADD(I,J,K)
.....
END
FINISH
and the call of TASK :-
TASK FORTRAN,*CR FRED,#CR0 DATA1,#CR1 DATA2
NB The #CR0 DATA1 could alternatively have been #CR DATA1.
If the program binary had an execution error, the TRACE2 system would give details of the last series of FORTRAN statements executed but users are reminded that this incurs a very heavy overhead in run times and should be used with care.
The use of a backing store by a FORTRAN program is also permitted. For example, consider a user wishing to read some data from a disc file, use a disc file for work space and write some results to another disc file. T he program might look like:-
PROGRAM(FORT)
INPUT 1=CR0
OUTPUT 2=LP0
INPUT 3=DA0/UNFORMATTED(A)
OUTPUT 4=DA1/UNFORMATTED(B)
USE 5=DA2/UNFORMATTED(C)
END
MASTER ABCD
.......
END
FINISH
and TASK could be used by:-
TASK FORTRAN,*CR FRED,#DA DADATA,#DA1 DAOUTPUT(WRITE),#DA2 DAWORK(WRITE)
DADATA, DAOUTPUT and DAWORK are all direct access files and must be created by the user (ie via GEORGE CREATE command). DADATA contains data written by another program and is read on FORTRAN channel 3. DAOUTPUT is written to by the program on FORTRAN channel 4 and DAWORK is used as a serial read/write area by the program on FORTRAN channel 5, Note the filenames in the PD (A, B and C) are dummies. CR0 and LP0 are catered for as previously indicated. The (WRITE) on the filenames are qualifiers which indicate the user wishes to write to the file and they are only needed for disc and magnetic tape applications.
Magnetic tape linkage is achieved in a similar manner, eg if FRED contained:-
PROGRAM(FORT)
INPUT 1=CR0
OUTPUT 2=LP0
INPUT 3=MT0/UNFORMATTED(A)
OUTPUT 4=MT1/UNFORMATTED(B)
USE 5=MT2/UNFORMATTED(C)
END
MASTER ABCD
.......
END
FINISH
it could be used by TASK as:-
TASK FORTRAN,*CR FRED,#MT MTDATA,#MT1 MTOUTPUT(WRITE),#MT2 MTWORK(WRITE)
In this instance the files MTDATA, MTOUTPUT and MTWORK are simulated magnetic tape files, MTDATA was written by a previous program and MTOUTPUT and MTWORK are generated by GEORGE in a similar manner to lineprinter output files. The use of MT files within the filestore is not recommended except when developing a program to process actual magnetic tape.
The onlining of actual peripherals to a FORTRAN program is slightly more complex. For direct access files these occur as exofiles (which are disc files outside the filestore proper). These are frequently used when a long program is heavily backing store limited since they are considerably faster than filestore direct access files. In the case of the DA example, consider a user who. has his data on an exofile EXDATA on disc 76. The TASK call now becomes:-
TASK FORTRAN,*CR FRED,#DA (76,EXDATA),#DA1 DAOUTPUT(WRITE), - #DA2 DAWORK(WRITE),MEDIA(EDS,1,(76))
Due to its length this TASK call cannot be typed in on one line on a MOP console and the - at the end of the first line (as illustrated in this example and others) indicates to GEORGE that the command is continued on the next line. The same technique can be used in background jobs.
Note the presence of the MEDIA parameter to notify the system that one[1] on-line peripheral is going to be used by this job which is an exofile [EDS] on disc 76 [76]. If he wishes to use an exofile for output a problem arises in that the format for a qualifier for the GEORGE on-line command differs considerably from the filestore assign command. TASK is unable to deal with the former and a special facility is available for users to get round this. This involves the user telling TASK the GEORGE command to use. Hence if the user had an exofile EXOUT on disc 76 which he wished to use as output, the TASK call would be:-
TASK FORTRAN,*CR FRED,#DA DADATA,#??(OL *DA1(WRITE),(76,EXOUT)),- #DA2 DAWORK(WRITE),MEDIA(EDS,1,(76))
TASK recognises #?? as being a GEORGE command enclosed in brackets. The media parameter is again present as an online peripheral is involved.
The onlining of magnetic tape creates similar problems. To obtain a scatch work tape the user simply puts the #MT parameter without a filename. For all other cases the #?? facility must be used. Thus for the magnetic tape case where MAGDATA is a 9-track magnetic tape, serial number 3241, containing the data, MAGOUT is another 9-track magnetic tape, serial number 3652, on which the output is to be written and both are owned by the user (ie are in his directory and trapped for him to read and write respectively) and a scratch 9-track work tape is to be used, the TASK call would be:-
TASK FORTRAN,*CR FRED,#??(OL *MT0,MAGDATA),#??(OL *MT1(WRITE),MAGOUT),- #MT2,MEDIA(TAPE9,3,(3241,3652))
Note the qualifier on the onlining of the MT1 to allow writing and the absence of a filename on MT2 to obtain a scratch work tape. The media parameter now specifies three (3) 9-track (TAPE9) magnetic tapes two of which have serial numbers 3241 and 3652.
As well as FORTRAN, TASK will also compile PLAN, PLASYD and ALGOL by replacing FORTRAN by the appropriate language name. Hence a PLASYD program in file FRED is compiled and executed by:-
TASK PLASYD,*CR FRED
All TASK's other features apply whatever the language and the binary from any language can be RUN by TASK.
An optimising FORTRAN compiler is also available and this is activated by using the additional parameter OPT. Thus in the basic example,to use the optimising compiler the user would input:-
TASK FORTRAN,*CR FRED,OPT
It is also possible to truncate several TASK parameters so long as the characters remaining denote a unique parameter. For example, FORTRAN may be represented as F, ALGOL as A, but PLASYD due to the similarity with the parameter PLAN, can only be truncated to PLAS, and PLAN cannot be truncated. Hence the basic example could be done by:-
TASK F,*CR FRED
This facility is especially useful because TASK uses the first three characters of the first parameter to generate a unique jobname when being used from a MOP terminal, (hence the requirement that the first parameter begins with a letter). For example, if a user had logged into MOP using the command:-
LOGIN JIM-MOP,:USER
then the TASK call:-
TASK FORTRAN,*CR FRED
would run a job named FOR-JIM-MOP. Thus if he wished to run a second job using FORTRAN, he would normally have to wait until the first job had finished due to the jobname clash. By using a truncated form he can overcome this, for example:-
TASK FO,*CR FRED
would run a job FO-JIM-MOP.
Users are reminded of the requirement to limit the number of background jobs in the machine at any one time (currently set at two).
As mentioned earlier the compilers produce an intermediate language known as semi-compiled. Since compilation can be a long process, large programs are often split into modules (eg one or more FORTRAN segments), compiled separately into semi-compiled and then all the semi-compiled consolidated together to form a binary program. Routines which are used in several programs are also often kept in semi-compiled form, as are the system library routines, eg the FORTRAN library.
Semi-compiled is generated at every compilation and to retain it in the filestore the user puts the parameter COMP. This will generate a default filename and store the semi-compiled in that file, overwriting any previous contents.
Taking the basic example, consider the user who wishes to include the subroutine ADD in several programs and to save the frequent recompilation he decides to store it in semi-compiled. In practice this decision would only be taken where large sections of a program were involved. He could have two files, FRED being:-
MASTER ABCD
READ(1,999)I,J
CALL ADD(I,J,K)
WRITE(2,998)K
STOP
999 FORMAT(2I0)
998 FORMAT(1X,I6)
END
FINISH
and ADD being:-
SUBROUTINE ADD(L,M,N)
N=L+M
RETURN
END
FINISH
Note both files terminate with a FINISH to indicate the end of the segment to be compiled.
To obtain ADD in semicompiled form the following is used:-
TASK FORTRAN,*CR ADD,COMP,NOCONS
This will compile the file ADD and put the semi-compiled in a file ADD-SEM. As has been stated previously, TASK will carry on to consolidate and execute the binary program and to prevent this, the parameter NOCONS standing for no consolidation is used. TASK will then stop after compilation. Had the user wished to use a different semi-compiled filename he could follow the COMP parameter by this, for example:-
TASK FORTRAN,*CR ADD,COMP MYSEM,NOCONS
would put the semi-compiled into MYSEM, again overwriting any previous contents. Note that a user can retain the semi-compiled in the filestore as well as consolidating it and running the binary program.
Now to compile FRED and then consolidate it with the semi-compiled from ADD and run the binary program, the following is used:-
TASK FORTRAN,*CR FRED,SEMI ADD-SEM,LINK
The SEMI parameter tells TASK to include semi-compiled from ADD-SEM at consolidation and LINK is a means of telling the consolidator to include ADD-SEM with the semi-compiled from FRED. The binary program would then be run using FRED-DAT for data.
Users may also include semi-compiled library routines in a similar manner. For instance, if the program FRED wished to use a routine in the NAG(Nottingham Algorithm Group) library the following would suffice:-
TASK FORTRAN,*CR FRED,LIB (26,NAGLIBF),LINK
The NAG library is held on an exofile which is external to the GEORGE filestore and is denoted by (26,NAGLIBF), in exactly the same manner as user exofiles.
Most system libraries are kept in this form, eg the FORTRAN library is (26,SUBGROUPSRF8).
The LIB parameter is used in place of SEMI to tell TASK when it LINKS the semi-compiled, only to include these semi-compiled routines in NAGLIBF that the program FRED wishes to use (indicated by the program having a CALL of that routine). Hence a LIB parameter causes a selective inclusion of semi-compiled and a SEMI parameter includes all the semi-compiled. Note that had a SEMI parameter been used instead of LIB, then the consolidator would have attempted to include the whole of the NAG FORTRAN library and, as this is rather large, would run out of store and fail.
As was illustrated by the ER,NORUN and NOCONS parameters in the early examples, it is possible to determine when TASK exits. These three and the parameter MAC form a family with very similar properties. The action of these parameters depends on the argument (if any) they are given and four possibilities exist.
If the argument begins with a digit, then it is regarded as a label and a GEORGE GOTO is obeyed on this label. This has been illustrated by ER 1ER in the examples of background jobs where in case of error TASK went to label 1ER.
If the argument is enclosed in brackets, the contents of the brackets are obeyed as a GEORGE command. For example, the parameter ER 1ER could alternatively have been ER (GOTO 1ER) and the contents of the brackets would have been obeyed if an error had been found.
If the argument is anything else, it is obeyed as a macro. Thus if a user had a macro ERRORMAC to deal with error conditions, the parameters ER ERRORMAC would activate the macro if an error was found.
The final case is where the argument is null and the action here depends on the parameter. NORUN and NOCONS, as has been illustrated, simply end the TASK at the appropriate point. ER on its own has no effect in simple usage.
MAC on its own generates a default macro call. In previous examples this would be equivalent to MAC FRED-MAC where FRED-MAC is the default macro name. The MAC parameter is used where a binary program is to be executed but the user wants to use his own macro to control this. TASK assigns all the specified and default peripherals and then obeys the macro call. In the macro the user can then assign any more peripherals and then enter the binary and can cater for any program halts etc. For example, if the user wished to use the output from one program as input to another he could write a macro FRED-MAC:-
AS *LP0,JIM-DAT LF JIM-DAT,*LP EN 0 IF DELETED(00),RJ JOBNAME7,TASK,RUN JIM-BIN
and use TASK by:-
TASK RUN FRED-BIN,MAC
In this instance the binary program FRED-BIN would be executed with data from FRED-DAT and would output on LP0 to a file JIM-DAT which is trapped for writing if it already exists. If the run is successful (FORTRAN binaries delete 00 if they end correctly), a second binary program JIM-BIN is run using JIM-DAT as input data. JIM-DAT is also listed on the lineprinter.
A much more efficient means of running jobs in a specified order is given in the Advanced Use of Task section.