There has recently been much discussion about the type of command to be provided with the on-line system. This has been accompanied by debate on the methods used to change phase, the significance of the stream and the status of the job description.
As a result of this discussion many suggestions have been made, and this planning document is submitted in the hope that it will help to clarify the existing position. The document contains a specific proposal derived from recent discussion and I hope it will be of value as a target for further debate.
As the number of compilers, editors and assemblers increases as the number of multi-phase jobs grows. Furthermore the sequencing of phases and the control of inter-phase links becomes more complex. We are moving naturally towards a system of phase controlling directives.
Unfortunately, these directives are being developed independently and as an integral part of each software package. This will undoubtedly lead to confusion and unnecessary maintenance activity unless these directives are recognised as being part of a higher level command language.
The interface between any two phases can be surprisingly simple at system level but in practice the growing tangle of conventions relating to the use of streams leads to difficulties. Since the use of the word stream has come to have more than one meaning it will be avoided where possible in this document.
The total interface phases consists of
These are created from paper tape or by output from an early phase. They include temporary BSD files as well as information in character form.
These are held on disc and administered through the file master or held on magnetic tape and organised by the programmer to suit himself.
An important simplification has already been made by defining just two data formats: Character string data and Block data. Furthermore the I/O extracodes will handle data equally successfully whether that data comes from a local or global document. It is only necessary for the programmer to ensure that the document is held in the appropriate format.
The distribution of data amongst the various available media is thus part of the operating strategy and is no concern to the object program. But this clean and attractive division of responsibilities is being eroded by the various 'stream switching' conventions. I suggest that these have arisen to overcome two organisational difficulties which are essentially irrelevant to the object program.
The position described above is that relating to off-line job organisation. However it is pertinent to observe that on-line activity will commonly resemble closely a multi-phase off-line job. It is possibly relevent, therefore, to consider both systems when conventions and software changes are debated.
The following proposal is believed to meet fully the criticisms and comments given above. The proposal involves a significant change to the present software. The change need not invalidate existing jobs. Some discussion of a compromise solution is given in section 3.
Job description consists of a JOB OUTLINE plus a COMMAND SEQUENCE. The job outline contains the following parts.
JOB ( ...... )
COMP EXEC LIMOUT LIMSTORE
each entry is terminated by newline or comma, entries are as follows :
Dn ( ...... )
T ( ...... )
F ( ...... )
D n HERE text *** H
the job will not enter execution until all of the requested items are loaded.
The Job Outline is terminated with *** U
The command sequence is a string of commands which are carried out as they are encountered. The first command follows the *** U which marks the end of the Job Outline. The string is terminated by *** Z or the command END.
Commands will be available for performing a variety of tasks and those connected with loading and executing program are described here.
In general a command is identified by a command name followed by data. This data can spread over several lines if enclosed in brackets, e.g.
EDIT [ ............ ............... ]
Stream handling is to be rationalised as follows :
The following directives are provided for running a job
INPUT, OUTPUT, BSD, SET, IIT, AUTOCODE etc.
This is followed by stream declarations separated by comma and newline e.g.
INPUT [ 1 D2 + F(AGF210/MPROG/MK.2), 2 T(AGF1/260)]
A declaration consists of an optional stream number (if ommited the No. is the equal to the No. of declarations already made since the past program execution) followed by a description of the document(s) to be used. In the above example stream 1 will be set up as the concatenated result of document D2 (set up probably in the job outline), followed by the file (AGF 210/MPROG/Mk.2)
If stream 1 was not already deleted then this stream will be taken before setting it up to the new value specified.
This is followed, like INPUT by a series of declarations e.g.
OUTPUT [ 0 PRINTER & D3
1 F(AGF210/RESULT/1714) ]
In this example output stream 0 is created by the command program and a copy of that which is sent to Output stream 0 will ultimately be printed. In addition the same information could be used in a later phase by writing INPUT [ D3 ]
These directives call the phases specified and assume that the necessary streams have been created. At the end of the phase one of two actions may take place.
The command stream may contain the commands
POSTMORTEM
and END
If a phase fails then the command switching program will scan the commands taking no action until it finds the POST MORTEM command. Subsequent commands will then be obeyed normally and the job terminated at END.
Under normal circumstances all commands between POSTMORTEM and END will be ignored.
An unmatched END command will terminate any job.
The documents Dn which are declared in the job outline or are created from an output stream (see OUTPUT) are to be regarded as files local to the job. The names of these files are local to the job and the life of any such file expires when the job terminates. The command program will see that the necessary filing action takes place. After any phase all output streams are closed and disposed of (except post portems - see above). The input streams however, remain untouched unless an over-riding declaration is made.
The DO command is used to call a 'command subroutine' which is the content of a specified file (or document). The name of this file can be followed by a parameter list e.g. (
DO [ F(AGF210/STANDARD/JOB) , D3, PRINTER]
In this command 'D3' and 'Printer' are parameters which can be referred to in the command subroutine as ~1 and ~2 respectively. The command END in the command subroutine terminates and the command switch program returns to the command following the DO.
The full list of elements which may be used to specify the source for an input stream using the INPUT command is as follows :
| Dn | Local Document called Dn |
| T (x/y) | The document held on the magnetic tape called x starting at block y |
| F (x) | The file called x |
| HERE | The document containing the text which follows the word HERE and terminated by ***h |
| ~n | The source specified by parameter n of a calling DO |
The full list of elements which may be used to specify the destination for an output stream using the OUTPUT command is as follows :
| D n | To be filed as local document Dn |
| T (x/y) | To go to block y on the tape called x |
| F (x) | To go to the file called x |
| Peripheral | To go to the named output peripheral. |
| The OUTPUT command may contain a statement of the output limit for the data on that stream. | |
| ~n | The destination specified by parameter n of a calling DO. |
Data may be processed in 512 word blocks from BSD n which is set up by the command BSD. This command is followed, like INPUT, by a list of declarations, one for each BSD, e.g.
BSD R1 F(AGF210/ data) , W2 F(AGF210/ new data)
The BSD number is preceded by R for Read Only, W for create a new file and U for update an existing file. The file may be specified as
| F (x) | File called x |
| T (x) | Magnetic tape called x |
| ~i | As specified by parameter i of a DO command. |
Part of the interface between phases is the content of the B-lines and it is possible that this part of the interface should be given more prominence. This may be done by such as the following :
The SET command would have the form
SET [ B10 = 2 , B11 = 16 , B12 = ~3]
The operand would be restricted to numeric literals or parameter calls.
The job outline and command sequences will undoubtedly be processes separately. The job outline by a job decoder and the commands by a command switching program.
The existing job decoder could be used by changing the notation and BSD naming system as follows :
Concatenation of input documents can be done in a number of ways. The cheapest is to provide a library routine which processes faults which arise from input stream exhausted. More satisfactory solutions would involve changes to the stream handling extracodes.
The command switching program would parallel the program with the same name which is used for on-line working. The off-line version could either be a 'compiler' or a complete program similar in status to the file master. If parameter substitution on DO commands is made at the time of the call then it means that the command switching program could satisfactorally operate as a compiler.
A modification to the 1117 extracode could tidy the system up a little and would endphase to the command program if the job is operating under the latter's control. To allow IIT and certain other, now standard, software to be made compatible with the existing system and the proposed extension it should be possible for a program to test whether it is operating under the command switching program.
AGF
12 September 1966
Copyright © 1966 University of Cambridge Computer Laboratory. Distributed by permission. Thanks to Barry Landy, Roger Needham and David Hartley for giving permission to distribute these documents. Thanks to Barry Landy for lending me the paper document from which this was scanned. Any typographical errors probably arose in the course of OCR.
Previous Planning Document: 15. Outline Scheme for
Log-in, Accounting and Control, DWB, August 1966
Next Planning Document: 17. Consoles other than
Teletypes and Character Equivalences (no date or author given)
Return to Cambridge Supervisor Planning Documents
Return to CUCPS TITAN page
Return to CUCPS home page
Return to University of Cambridge home page