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.
CCP is entered on the following conditions:
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.
A command is read from the console record by record, and processed according to the following rules:
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:
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:
(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.
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:
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.
If the command name does not include a '/' character, a similar process loads the file with title:
LIBRARY/command name/*
The following commands should be provided in the first instance; most of them would be held with CCP.
USER | file name | ) | temporary | |||
) | ||||||
FINISH | ) | |||||
INPUT | the following lines up to the signalling control character become input P1. | |||||
FILE | file name | a copy of input 1 is filed; also input streams 2 - 10 are closed. | ||||
DELETE | file name | the file is deleted; also input streams 2 - 10 are closed. | ||||
TYPE | ) | a copy of input 1 is | ( | typed | ||
) | ( | printed | ||||
PUNCH | ) | ( | punched |
If followed by a file name, that file is first opened as input 1 (p-type.)
IIT | ) | |
AUTOCODE | ) | as at present |
EDIT | ) |
If followed by a file name, that file is first opened as input 1 (p-type).
DFH
21.10.66
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