Cambridge Supervisor : Planning Document 16
Commands and Job Organisation

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.

1. The existing position

1.1 Changing Phase

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.

1.2 The interface between phases.

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

  1. The B-lines
  2. Local Documents

    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.

  3. Global Documents

    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.

  1. The common need to concatenate several documents and so form one logical string of information for processing.
  2. The need to change the logical numbering of data to meet the different conventions of each phase.

1.3 The on-line system

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.

2. A Proposal for Job organisation

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.

  1. A heading of the form.
    JOB ( ...... )
  2. A selection from the directives
  3. A list of items to be loaded before the job can run preceded by the word LOAD

    each entry is terminated by newline or comma, entries are as follows :

    1. for a card or paper tape document
      Dn  ( ...... )
    2. for magnetic tape
      T  ( ...... )
    3. for a file on disc
      F  ( ...... )
    4. for a small document in the body of the job outline
      D n  HERE
      *** 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 :

  1. IIT and compilers will normally read from just one stream. If that stream is the concatenated result from several different sources this will be handled by the command program.
  2. Programs which previously output the same data on several streams will use just one stream and the command program will handle the copying process.
  3. Compilers, editors and IIT will normally compile from stream 1 and output onto stream 1. Edit commands will be read on stream 0 and diagnostics produced on stream 0.
  4. Programs will usually assume all input and output streams to be created by the command program before entry. For essential output (e.g. object program of a compiler) a pending stream will be created if the appropriate stream has not been set up. For diagnostics etc. a printer stream will be created where it has not already been set up. Not more than 8 output streams should be created from within the program.
  5. Stream numbers in the range 0 to 15 only will be used by a normal object program. The command switching program will itself use stream numbers outside this range.


The following directives are provided for running a job



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.

          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 ]

(c) IIT, AUTOCODE etc.

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.

  1. If the job monitored then the command program will search for a POST MORTEM (see below).
  2. If the job was successful the output streams will be disposed of by sending all those declared in OUTPUT commands to their respective destinations. All output streams created internally will be closed and either sent to the appropriate peripheral or, if pending, output stream n will be concatenated with th remaining input (if any) on input stream n leaving input stream n set up.

Post Mortems.

The command stream may contain the commands

   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.

2.6 Local documents

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.

2.7. Macro Commands

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. (


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.

2.8 Input Specification

The full list of elements which may be used to specify the source for an input stream using the INPUT command is as follows :
DnLocal 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
HEREThe document containing the text which follows the word HERE and terminated by ***h
~nThe source specified by parameter n of a calling DO

2.9 Output specification

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 nTo 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
PeripheralTo go to the named output peripheral.
The OUTPUT command may contain a statement of the output limit for the data on that stream.
~nThe destination specified by parameter n of a calling DO.

2.10 Backing Store Device Mode

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
~iAs specified by parameter i of a DO command.

2.11 Setting B-lines.

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 :

  1. The first x B-lines only form part of the interface.
  2. The command SET may be used to set up any or all of these B-lines for the next phase entered.
  3. All B-line values not defined by SET are as left by the previous phase.
  4. Loaders should preserve the interface B-lines.

    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 :

  1. for LOAD use the existing INPUT and TAPE headings.
  2. use tape numbers in place of titles
  3. use Dn in the input section as described for the LOAD section but deny to the user the side effect of setting up stream number n.

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.

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

Contact: CUCPS Committee (
This HTML version last updated: $Date: 1999/06/14 10:59:50 $