During 1966 various methods of providing some multi-access facilities on the Chilton Atlas I computer were investigated. The following criteria determined the design of the proposed system.
The use of a satellite computer for controlling terminals and providing file handling capabilities was considered to be an ideal way of satisfying these criteria. Moreover, the recent addition of a large Data Products disc file to the Atlas system would provide a means of communication between the two machines. The satellite computer chosen was an XDS Sigma 2 because it satisfied the following requirements.
The initial configuration was 32K core store, 16-bit word (16K integral store with 0.9 µsec cycle time, 16K external store with 1.1 µsec cycle time, the latter being directly accessible by the disc), paper tape reader/punch, card reader, control console, and 6 ASR 35 Teletype terminals. Fig. 1 shows in outline how the two machines were linked.
The design of multi-access computer systems had been reviewed by Wilkes (1967, 1968) and Wilkes and Needham (1968). However, there is a lack of evidence in the literature of the use of a satellite computer for performing all of the system tasks except those of compilation and execution of user programs. These tasks are:
This paper describes how these facilities have been implemented with a relatively small amount of programming effort and negligible inconvenience to the operation of the main machine.
The multi-access system is primarily geared to Teletype terminals working in full duplex mode. Thus, Sigma 2 accepts terminal input, character by character on an interrupt basis, and only echoes a character if input is expected at that time. Instances of input not being expected occur during terminal output (except for the BREAK key which has the expected function of interruption), or while a command is being obeyed.
Normal local editing facilities are available for deletion of mis-typed characters or of a line. The choice of characters to perform these functions is left to the user. In addition, the Teletype RU character has a similar effect to the DUP button on a card punch. A software tabulate facility exists under user control. Half-duplex working is possible but the power of the two latter facilities is then somewhat restricted.
Alphanumeric displays (Cossor DIDS 402) and 1900-modified Teletypes have subsequently been incorporated into the system with relative ease.
The Atlas operating system provides no file handling capabilities, but works instead in terms of documents (Howarth, Payne and Sumner, 1961). The multi-access system therefore had to provide such facilities, using the Data Products disc for file storage.
Throughout the Atlas system, storage is assigned in terms of blocks of 512 48-bit words (Kilburn, Howarth, Payne, and Sumner, 1961). For Atlas convenience, the disc is similarly structured and, of the total capacity of 32K blocks, 6K disc blocks have been reserved for the storage of system files. One block is equivalent to 1,536 Sigma 2 16-bit words and the filing system preserves this structure, making no attempt to pack files. A file is therefore a minimum of one block in length.
A master file directory is maintained in Sigma 2 store giving information about every user known to the system. Such information is the disc address of his file directory, his password, local editing characters, tab settings, and various flags. This directory is preserved on disc between sessions. An entry in the user's file directory gives the file title, the disc address of the first block of the file, the date and time of its creation, its usage count, status, accessibility, and other similar information. A file consists of one or more chained blocks of disc space. Each block comprises the forward pointer followed by the records of the file, each record being headed by a 16-bit line number and terminated by a newline character. The body of the record is text in EBCDIC characters, two per word. Binary files are not permitted.
Blocks of disc which are unused for files are identified by keeping a block usage directory in store. This is a table of bits in which each bit corresponds to a block of file space on the disc. Any bit set to zero indicates that the corresponding block is available for use.
The file handling strategies adopted by the system are as follows:
A file title comprises two parts: user identification/filename. When referencing one's own files, this may be abbreviated to filename. A series of public files exists for general use and may be referenced as SYSTEM/filename or, more conveniently, /filename.
To allow a user to have control over who may access his files, every file can be given a status for each of three groups of user. The user groups are:
The types of access are:
A user, accessing someone else's file, will be asked for a key if and only if the public do not have the required status but keyholders do. (See Fraser, 1968 for a similar, but more complicated, system.)
A count is kept of the number of times each user group accesses the contents of a file. As well as being of statistical value from the system standpoint, this information gives the user some indication of the popularity of a given file.
A file may be designated as temporary or permanent. Each user has an allocation of permanent file space and when this limit is reached he may only create temporary files. The system deletes temporary files older than one month and, although this method of reclaiming unwanted disc space is not as sophisticated as that in use at Cambridge (Hartley and Needham, 1969), it is better than the time since last access method, as a user may massage only his own files. There must of course be sufficient room in the system at the time for this to be possible. In practice, this method has worked quite well. The total available file space has been fully utilised on two or three occasions only, and users have been able to overcome the problem by suitably re-arranging their files. It is easy for them to save files not in current use on Atlas tape, and restore them when required.
A special one block message file may be created for a user if another system user inputs a message for him. This file can only be read or deleted by the addressee (the owner) and it may not be edited. It exists only if there is a message pending. Further messages are concatenated to a maximum length of one block. After reading the messages, each of which is tagged with the sender's user identification and the date and time of its creation, the owner is given the option of saving the file or deleting it. A warning message is sent to the owner whenever a message is input to the file, or, if the file exists at that time, immediately after logging in.
Because the hardware has been very reliable, the only file safeguard provided is a weekly dump of the whole system on to two Atlas magnetic tapes. We have found it necessary to restore the system completely only two or three times since its inception, and it is possible to recover an individual file from these tapes if a user has accidentally deleted it, for example. Dump tapes are retained for two weeks before being re-used.
The command language and error messages have been chosen both for ease of use by a newcomer to the system and the ability to decipher terminal hardcopy at some subsequent date. Thus, with few exceptions, commands are full English words followed possibly by argument phrases which may be ordered as desired. The following are all acceptable:
TYPE FILENAME NUMBERED FROM 10 TO 50 TYPE FILENAME TO 50 NUMBERED FROM 10 TYPE FILENAME FROM 10 TO 50 NUMBERED
Should a user wish to minimise the amount of typing, the qualifiers such as TO, FROM, and NUMBERED in the above example may be replaced by commas, with the restriction that the arguments must then come in a predefined sequence, i.e.
TYPE FILENAME, 10,50,
Commands are provided for creating, copying, concatenating, deleting, expanding, and renaming files. Two editors exist: one involves updating by reference to complete lines using line numbers and the other is, for the most part, a context editor.
The first editor is straightforward, new lines being identified by their line numbers. Whether these are replacement lines or inserted lines depends on the numbering system in the original file. This editor was written first, and is fast. All its functions are now included in the second editor.
The context editor uses single letter commands and allows the user a choice of string delimiter by context with each command which references a string. The delimiter may not be a letter or a digit, however, and commands which require no strings or numbers must be followed by a space or newline character. This is to prevent the mistaken typing of system commands being accepted as bona fide edit commands whilst still in the editing mode. The user may select a line by context or line number, and then alter it, replace it, or insert more lines after it. The corrected line is output if required. The user may also specify a character to represent an arbitrary string of characters when searching for a string (thus enabling him to look for the occurrence of a number of strings separated by an unknown number of characters). A series of commands may be selected to be obeyed repetitively, a check being included to detect any infinite loops produced in error.
A file comprising a series of system commands can be executed by use of the APPLY command, and any formal parameters within the file will be replaced by actual parameters supplied with the APPLY command. Thus, we might have a file containing the commands
RENAME <2> AS <1> TYPE <1> NUMBERED
The command
APPLY FILENAME USING FRED AND JIM
input at a terminal will cause the commands
RENAME JIM AS FRED TYPE FRED NUMBERED
to be obeyed. If required, each command line can be output as it is obeyed. Taking commands from a file in this way can be interrupted by the use of the BREAK key.
Atlas job initiation is achieved by specifying a file either to be RUN or to be SUBMITted. That file, which may also contain formal parameters, will be sent, after appropriate modification, to Atlas along the peripheral link between the two machines. Its length is restricted (to one block) and it must start with an Atlas job description (see Howarth et al., 1961). If the file is SUBMITted, no reference to the file system may be made in the job description and no further knowledge of the job is retained by the system. This allows a user true remote job entry capability with small jobs, and any number of such jobs may be run. If the file is RUN, however, other system files may be used as input streams and these will be translated into Atlas internal code and placed in an intercommunication region on the disc in an appropriate format. System files may also be nominated as output streams. An additional output stream is put into the job description by the RUN command code to enable Sigma 2 to recognise completion of the job in Atlas (making use of the fact that, under normal conditions, Atlas does not transmit output to an actual peripheral from its output well until the whole job has completely finished). While the job is being processed by Atlas, the user may use all the facilities of the system except that of RUNning another Atlas job (although he may still use SUBMIT).
The response to the RUN command varies with the workload in Atlas. However, short jobs initiated in this way are given priority, so it is not at all uncommon for the response to be immediate (i.e. before the system can request a new command from the user).
Direct transfer of information between core and the Data Products disc is restricted to the upper 16K of Sigma 2 store (i.e. the external memory). Consequently, the system code resides mainly in the low 16K and the upper 16K is used for a series of buffers (at present the system is wholly core resident).
Disc information is transferred in 1,536 Sigma 2 word blocks and several disc buffers of this size are provided. The number of buffers actually used is a variable parameter of the system and is normally set at four. These are used only when a transfer is necessary and are released as soon as possible afterwards.
To permit intermediate storage of information, such as during the creation of a file when terminal input is being accumulated, a variable number (usually 20) of small buffers is provided. Each contains space for 192 characters of information and some linking and pointer words. Small buffers are allocated as required and linked together until either input ceases or no more buffers are available. A disc buffer is then sought, filled, the transfer completed, and the disc buffer released. All but one of the small buffers are then returned to the free list, and either the input process restarts or the remaining buffer is released and control passed back to the command mode.
Requests for disc buffers and disc transfers are queued and a priority system is used to prevent any request waiting for any length of time on both queues. Small buffer requests are not queued and it is left to the command code to take appropriate action if one is unavailable. In such circumstances, however, an alarm flag is set and any user possessing a chain of small buffers is forced to release them as soon as convenient.
Whenever a terminal becomes active, an 82 character teletype buffer is provided for input line images.
As each user is accepted by the system, he is given a user work area about 45 words long, This is for use by the re-entrant code in which the system is written. Instead of using a time slicing system, each user is allowed to continue obeying code until he requires some input/output activity. This may be a disc transfer or some terminal transfer. At that time he is suspended and the next user free to go is activated. When the necessary transfer has been completed, the original user is marked ready to go. Thus, between halts the code can use local workspace, but across them information must be stored in the user work area. Very little useful work can be done before an i/o activity of some sort is required (no arithmetic is performed by the system) and the adequacy of the algorithm is borne out by the good terminal response.
The Sigma 2 control console is used for manual system control. By this means, the operator can start up and close down a multi-access session, can selectively engage various terminals, control the rate of Atlas job initiation, enter new users into the system, demand statistical and post-mortem type dumps, and output urgent messages on active terminals. In addition, this console is used for monitoring activity on the Atlas peripheral link. The system is not dependent on this console, however. If it is inoperable for some reason, control input and monitor output can be accepted by the other available peripherals.
Automatic control and monitoring of the system is provided by a series of software clocks. A clock can be assigned a particular function and, once turned on by a routine call, will be incremented at each interrupt of the 2 millisecond hardware clock. Alternatively, it may simply be used as a counter (to count disc transfers for example). Thus it is possible to determine how much processing time a user has taken, how long the system has spent in the idle loop, or how long a user has been inactive at a terminal (which provides the means of auto logout for the user who just walks away from his terminal). A particularly valuable feature of these clocks is their use in determining the performance of various parts of the system software.
Statistical information, in the form of records containing identifying letters, numbers, and the clock time, can be collected for later analysis from any part of the system. Initially, the only available output medium was the paper tape punch, which produced output for subsequent processing by programs in Atlas. However, the system now includes a fixed head disc (RAD), on which the output may be accumulated. The acquisition of the RAD, and of a lineprinter, has enabled us to use some of the manufacturer's software (RBM), and the analysis programs now run under this control. So far, the statistics have been used to verify a mathematical model of the system, and a paper on the results was presented at Datafair 71.
Throughout the writing of the system, Atlas was used where appropriate. For example, a Sigma 2 simulator was written before delivery of the machine. Moreover, a series of utility programs was provided for file dumping, purging outdated temporary files, and file verification (the last duplicating a file verification program now run under RBM). A complete Sigma 2 core store image of the system is written to the disc by means of an Atlas loader program which is far more sophisticated than would be easily possible using only Sigma 2. This loader provides limited editing facilities, a detailed storage map, and a concordance option.
Since the initial configuration, the Sigma 2 has been upgraded by the addition of a lineprinter and a RAD (already mentioned above). Also two alphanumeric displays and 14 more Teletypes (mainly ASR33) have been added. The system is available as an in-house facility each evening and for most of the working day. It is then shut down to allow for further development. Currently, of the 22 terminals, up to 8 may be active, 4 of which may be remote from the Chilton site. The system was released in May 1969 after a total development time of approximately 24 man-months of work.
This work has shown that a non-interactive system of this type using a satellite computer to provide ready manipulation of user tiles has much to commend it, especially in an environment where throughput of work on the main computer is of prime importance. It should also be noted that a change in the large machine involves, apart from the hardware interface, changes to the code of the RUN command, and tile translation, only. Thus continuity of system can be provided when upgrading the main computer to a new generation of hardware.
Our thanks are due to P. Wilde of the Rutherford High Energy Laboratory for designing and building the interface between Sigma 2 and the disc, the peripheral link between the two machines, and the software associated with the disc queue. We also acknowledge the assistance of W. F. Lunnon and S. H. Michael in writing parts of the system. Although the detailed system design and implementation is the work of the present authors, the original proposal for using an intelligent front-end processor in this way was due to M. H. J. Baylis (Baylis 1966).
1. Baylis, M. H. J. (1966). Time-sharing and Atlas, Some Aspects of Current Operation and Research, Atlas Computer Laboratory.
2. Fraser, A. G. (1968). File integrity in a disc-based multi-access system, International Seminar on File Organisation, Publication of Working Papers, 395.
3. Hartley, D. F., and Needham, R. M. (1969). Operation experience with the Cambridge multiaccess system, lEE Conference Publication No. 55, 255-260.
4. Howarth, D. J., Payne, R. B., and Sumner, F. H. (1961). The Manchester University Atlas operating system: Part II Users' description, Computer Journal, 4, 226--229.
5. Kilburn, T., Howarth, D. J., Payne, R. B., and Sumner, F. H. (1961). The Manchester University Atlas operating system: Part I Internal organisation, Computer Journal, 4, 222-225.
6. Wilkes, M. V. (1967). The design of multiple-access computer systems, Computer Journal, 10, 1-9.
7. Wilkes, M. V. (1968). Time Sharing Computer Systems, London: Macdonald and Co. (Computer Monograph Series No.5).
8. Wilkes, M. V., and Needham, R. M. (1968). The design of multiple-access computer systems: Part 2, Computer Journal, 10, 315-320.
[This paper first appeared in Computer Journal, 14 (1971), 119. It is reproduced here (with amendments to bring it up to date) by permission of the British Computer Society.]
