Command Control Program - Proposals


This document gives a brief outline of proposals for the Command Control Program (CCP). These I regard as one step further forward from the present status of CCP, and is based both on recent practical experience and on various principles that we have tended to lay down for the future. It is my opinion that we have still some way to go in this development, but, if the following proposals are approved, they can be implemented through simple modifications to the present CCP.

2. CCP Entry

CCP is entered on the following conditions:

  1. When any character is typed on an otherwise dormant console (i.e. when the console is not "logged-in"). There is also a switch set which implies "not logged-in".
  2. When a phase of the job (other than CCP itself) obeys either an 1117 extracode or monitors; in the latter case the reason for monitoring is available to CCP.

The action of CCP is as follows. If the switch indicates "not logged-in", CCP behaves as though a hypothetical 'LOGIN' command had been typed, and causes entry to the appropriate program, which deals with any logging in procedure, sets input stream D0 from the console and output stream 0 to the console, and sets the switch to "logged in". If the reason for entering CCP is one of certain faults (e.g. time expired) CCP similarly behaves as though a "LOGOUT" command had been typed, etc. Otherwise CCP outputs "READY" on a newline, deletes any extraneous input from the console, and waits for a command to be typed. In the case of any fault causing entry to CCP, input D0 and output 0 are reset to be from and to the console respectively.

3. Command Decoding

A command is read from the console record by record, and processed according to the following rules:

  1. Any initial spaces or tabs are ignored;
  2. The name of the command consists of any number of characters other than comma, tab, round brackets or newline, and is terminated by such a character;
  3. Apart from terminating a name, spaces or tabs immediately following the name are otherwise ignored;
  4. Further characters form the parameter string, and in reading this, CCP keeps a count of the level of round brackets and both the parameter string and the command are terminated by a carriage control character at level zero.
  5. The characters of the parameter string are first output on output stream 254 as pending, and then renamed as input 253 (d-type).

4. Parameter Decoding

Since the commands themselves are not necessarily stored with CCP and must as far as possible be able to do their own parameter decoding, the processing as described below is done by CCP for all commands.

If, in command decoding, CCP had noticed that the first significant character of the parameter string was an opening bracket, then the following occurs. The parameter string is assumed in general to begin with three lists of items: the items of a list are separated by commas, and each list is enclosed in round brackets; the lists themselves are separated by commas, and the whole thing is also enclosed in brackets. The items are each one of the following forms:

  1. a file name
  2. an "=" sign, possibly followed by other characters
  3. empty

Non-significant spaces are ignored except that a space may be used to separate two non-empty items or lists. If a list is totally empty or consists of only one item, the brackets enclosing the list may be omitted. A list that is absent in this way need not be followed by a separator if all following lists are similarly empty and not followed by a separator.

The lists correspond respectively to input streams, output streams and backing-store devices (block files); in each case, the nth item corresponds to stream or device n. If any list is less than 10 items long it is taken as though the missing items are "empty". The effect of each item is as follows:

  1. file name - the stream or device is closed if it exists and re-opened as the quoted file
  2. = - the stream or device is left in its current state
  3. empty - the stream or device is closed if it exists.

(It is suggested that a further development might be to implement "=" followed by certain characters to give other sources and destinations etc. (particularly streams to and from consoles); but all this needs further thought.

Note that the process just described does not treat input stream 1 (i.e. the current document) specially; and thus, if a command specifies parameters in this way, the current document may be affected. Note also that any further characters in the parameter string remain in input 253, and can be read by the command itself.

5. Command Entry

For the sake of efficiency and expediency certain commands will be implemented by programs stored with CCP itself, and these may well use common facilities, particularly those described above in Section 4. Otherwise, there are just 2 standard ways of entering a command:

(a) Private Commands

If the command name contains a '/' character, it is assumed to be the name of a file. CCP opens this file as backing-store device 126, and a change phase extracode is obeyed to obtain 1 block of J0 space, load block 1 of the file into it, and enters at address 0.

(b) Public Commands

If the command name does not include a '/' character, a similar process loads the file with title:

LIBRARY/command name/*

6. Notes

  1. The supervisor is such that the signalling control character which causes fault 94 (i.e. "return to CCP"), in fact causes 65 if CCP is in control. The action of fault 65 is to cause a re-entry; thus, to accept a new command.
  2. The current document technique remains in its present external form as input stream 1; except that there would not normally be a new current document produced by using IIT, AUTOCODE etc. commands, unless explicit steps were taken by the programmer either through commands or through program. Commands such as EDIT must be modified to do more of the work associated with the "current document" within itself.

7. Basic Commands

The following commands should be provided in the first instance; most of them would be held with CCP.

(a) More or less essential

USERfile name)temporary
INPUTthe following lines up to the signalling control character become input P1.
FILEfile name    a copy of input 1 is filed; also input streams 2 - 10 are closed.
DELETEfile namethe file is deleted; also input streams 2 - 10 are closed.
TYPE)a copy of input 1 is(typed

If followed by a file name, that file is first opened as input 1 (p-type.)
AUTOCODE)as at present

If followed by a file name, that file is first opened as input 1 (p-type).

(b) Highly desirable

  1. Command to connect a further console to the user.
  2. Command(s) to open and close input/output streams and backing-store devices, other than provided by the mechanism described in Section 4.
  3. Commands for further file operations (change status, directory printing etc.)


There is also a supplement to this document by DFH, dated 1 November 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: 19. A proposal for control signals and break, JCV, 8 October 1966
Next Planning Document: 21. Log-in Accounting and Control - Pilot Scheme, JMHH, 1 November 1966 (plus Logging in and Control : System 1, JMHH, 4.2.67)
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/21 20:32:09 $