Contact us Heritage collections Image license terms
HOME ACL Associates Technology Literature Applications Society Software revisited
Further reading □ OverviewBaylisSystemModellingEvaluationDisc1. Atlas Op Sys2. Atlas Op SysCOLAB □ Manuals □ Data Products Disc 5045Sigma2 Reference ManualMulti-Access ManualOperator's Guide
ACD C&A INF CCD CISD Archives Contact us Heritage archives Image license terms

Search

   
ACLTechnologySigma 2
ACLTechnologySigma 2
ACL ACD C&A INF CCD CISD Archives
Further reading

Overview
Baylis
System
Modelling
Evaluation
Disc
1. Atlas Op Sys
2. Atlas Op Sys
COLAB
Manuals
Data Products Disc 5045
Sigma2 Reference Manual
Multi-Access Manual
Operator's Guide

What Was, What Is and What Should Have Been:. A Critical Evaluation of the Chilton Multi-Access System

Eric Thomas and John Baldwin

1972

Introduction

The Chilton multi-access system has been described elsewhere. Essentially it comprises a triangular arrangement between an Atlas system (running normal batch work), a satellite computer: (used for all of the multi-access system tasks, except that of compilation and execution of user programs) and a large disk file (conceptually split into sections private to each machine, and an intercommunication region through which. large files are passed).

When the system was released to users (May 1969), it found a surprisingly ready acceptance both amongst those used to different systems and those new to multi-access working. Our experience indicates that this is not normally the case and we would consider the following as contributing factors.

  1. Clearly stated objectives.
  2. Straightforward commands and diagnostics.
  3. No current file (all file names are stated explicitly)
  4. The simplicity of the Atlas job control language
  5. Lucid documentation

Eric Thomas and John Baldwin with the Sigma 2

Eric Thomas and John Baldwin with the Sigma 2
Full image ⇗
© UKRI Science and Technology Facilities Council

The remainder of this paper indicates the enhancements found necessary to the original system and, examines the areas which, with hindsight, are now felt to be sensitive in the implementation.

ENHANCEMENTS

Some extensions of the system were described in Reference 1. Principally these were. the incorporation of different terminal devices and the provision of a good context editor.

The addition of the fixed head disk (RAD) to the satellite configuration enabled a more satisfactory means of collecting and analysing the statistics of machine resource usage. Previously, the only output device available for such data was a paper tape punch, the capacity of which was soon outgrown by the volume of data recorded. It also allowed the use of the manufacturer's operating system (RBM) - outside the multi-access sessions-for routine compilation, file verification and purging (i.e. consistency checks and the removal of out-of-date material) and the like.

Users felt that the restriction of having, at most, only one job in Atlas at any one time somewhat irksome. (In fact, this restriction was imposed by management.) With very little programming effort, it was possible to introduce an additional command, SUBMIT, identical to RUN with the exception that additional files were not allowed for input or output streams. Management was satisfied that jobs with these characteristics would not overburden Atlas and thus a user was allowed to initiate as many Atlas jobs as he chose providing that each did not exceed approximately 4,000 input characters (i.e. one block of input) and that each only used Atlas peripherals for output. If he required access to other files, however, he still had to use RUN and the original restriction remained.

The anticipated rewrite of the system using a high-level language did not in fact materialize. Although one would like to feel that the primary reason for not doing so was the success of the initial system, other factors such as shortage of manpower for other projects and the retirement of the Atlas machine (the implications of which are discussed later) were dominant.

TERMINALS

Originally, the Atlas Laboratory purchased Model 35 Teletypes for use with the system. These are large and relatively expensive and, although they are in general more reliable than the smaller machines, cheaper, quieter devices are found to be. more amenable.

John Baldwin and Teletype. attached to Sigma2

John Baldwin and Teletype. attached to Sigma2
Full image ⇗
© UKRI Science and Technology Facilities Council

Quietness is an important factor, especially when the terminal is situated in an office occupied by two or more people. Message-oriented displays were also attached, but for ease of coding they were used as line-by-line devices. The need to poll such displays and the possibility of large quantities of input are disadvantages in a basically Teletype system, and use was not made of their greater speed capability. Far better in this context are the Teletype-substitute displays, which are considerably cheaper, need no special programming to connect them and are silent. Whether hard copy is required or not is very much a matter for personal taste: experience has shown that there are always some occasions when hard copy is needed (particularly when investigating claims about system malfunctions). The ideal hard copy device here seems to be a small portable fast printer which can be quickly connected when required.

Eric Thomas and Cossor DIDS 402A Terminal

Eric Thomas and Cossor DIDS 402A Terminal
Full image ⇗
© UKRI Science and Technology Facilities Council

The system was designed to deal with terminals working in full duplex mode although, with the advent of external users with different terminal equipment, it was found necessary to accommodate half-duplex working (and, incidentally, 1900-modified Teletypes). The full duplex method has a number of advantages: in particular, by causing the machine to echo characters, some confidence is gained from the fact that the machine has actually received what was typed. Also, it is possible to suppress the echo for passwords and the like, or even echo one character by another or by many. Software tabulating was thus implemented allowing the user to specify his own settings, the input routine substituting the appropriate number of spaces. Also, one control character (the RU key) was designated a duplicate button. Use of this key resurrects the character currently in the input buffer. at that column position. Thus, if an error is detected in the middle of a line, the line can be cancelled and the original correct part of the line copied, avoiding further error. Indeed, if the correction required is a one-for-one replacement, the rest of the line can be copied in the same way. This simple facility does not appear to be generally available on other systems.

The system also allows a user to choose his own local editing characters. Thus, he may express his personal preference for the symbol which means delete the last character or delete this line. This also enables use of the full character set within a file.

THE FILING SYSTEM

The restriction of the user's file directory to one block (ninety-five file entries) meant that there was no great overhead in opening files for access. In fact, it was possible to include the luxury of a count of the usage of the file in each entry, which entails an extra disk transfer per initial file access. This count has proved interesting and gives an indication of the popularity of library files, but otherwise is not really used.

The choice of three classes of user of a file (any one accessing a file is classed as owner, keyholder or public) has proved one too many since there is no requirement in the Laboratory for the added security of keyholder status. Thus two classes, owner and public, would have been sufficient. This of course might not be true in a university environment, where the need for careful security arrangements is often paramount (the undergraduate problem!). However, the ability to prevent oneself from deleting a file has been found to be very beneficial by those who have, in error, typed a DELETE command with the wrong filename! It is surprising that some systems do not provide this safeguard.

The file concepts have proved very successful. The fact that there is no current file, made possible by the ease of file access, means that there is no room for doubt as to which files are being accessed by a given command. Prevention of file access when anyone is trying to write to that file avoids any problems as to which version of a file any other user would receive, and the removal of a file only by an explicit DELETE command further prevents the accidental erasure of important material.

The layout of files on backing store, however, could be improved. Lack of non-record-oriented binary information in files (no user programs can be executed on the satellite machine itself) has allowed us to have simple linked lists of blocks. The chosen format of a file record comprises an initial line number, followed by the characters of the text up to a newline character. The inclusion of line numbers meant that a very simple line editor was provided, but this has been superseded by a full context editor and the line numbers have now fallen into disuse. However, there is much to be said for files not being renumbered every time they are edited, particularly when an on-line manual, say, is being updated. Since one may not be sure that a chosen context is unique, it is usual to locate the area to be edited approximately by means of line numbers. If line numbers are retained explicitly, there is no necessity to obtain a revised line numbered listing every time the file is edited. The choice of a record delimiting character has prevented the easy inclusion of graphical equipment which produces pictures in character form, in which each character needs to be interpreted as binary. An improved system would replace the line number by a character count; this would remove the need for an end-of-record character and would speed searches by the editor through a file.

The decision not to have a chain of free blocks (but instead to have a bit map indicating used blocks) has proved very useful. When a free block is required, the one with the lowest disk address is allocated, rather than the one which was handed back last. In this way, files have tended to be built up from sections of sequential blocks, which has assisted file access. It was decided to increase the work done by the DELETE command by zeroing the link in each deleted block. Thus, if the file system gets itself corrupted for any reason, the accidental acquisition of an extra free block by a file cannot add any more blocks from some long-dead chain. After a crash, the bit map can be reconstructed from the current system by following down each chain (a five-minute Job) and a warm restart effected. By pre-setting bits in this table, some blocks can be permanently locked out; allowing for variable engineering areas in the system and the removal of blocks which are in error.

The provision of a telex facility by the use of a message file has been helpful, particularly to a user wishing to ask a question about his current work. It would have been more hygienic, however, to have made this file in form similar to other files in the system so that a user could correct a message, and perhaps copy sections from his message file to another file. It would have been better, too, to have stored messages in reverse order of time entered; so that a user could always read the most recent ones first.

Space was left in the directory so that an incremental file dump system could be incorporated at a later date. However, the hardware has proved so reliable that the only dumping necessary has been a full weekly dump. It is possible to recover individual files from the dump tapes, even those files which have subsequently been deleted. A simple system of rationing disk space by allocating temporary file space (unlimited in amount - to the maximum available - but likely to disappear after a month) and permanent file space (a limited amount) has worked to date, and users seem able to remember to delete unwanted material. This is not true in general, of course; it is essential that the policing of file space usage be made as flexible and as complete as possible, and that the problem be tackled at an early stage in the system design.

COMMANDS

The use. of full words for system commands, with single letter commands being only used in the editor, has helped to prevent typing errors from causing untold damage. To facilitate discovery of such errors, de1imiters for strings in edit commands are restricted to non-alphanumeric characters and any edit command which does not require an argument must be followed by a space or newline. The editor is indeed simple and in addition to the usual commands, includes a general global facility and the ability to represent an arbitrary string by one symbol. There are a number of drawbacks, however. The form of the records in a file (see above) makes it difficult to search for strings which contain the newline character. There is no provision for the insertion of a file, either partial or complete, into another by one instruction and, since the edited material is transformed directly into a new file (although a pseudo-command has been designed to give the illusion of using only one file - see below), commands must proceed in sequence through the file. This last restriction is tempered somewhat by allowing freedom of action within the current source line. The editor also allows verification of the corrected line after editing - an essential feature of any useful context editor.

The APPLY command (i.e. the taking of system commands from a file rather than the keyboard), with the possibility of using parameters, has also proved advantageous. It includes the ability to either print each command as it is being obeyed (for safety), or suppress this printing (useful when constructing long pseudo-commands). By the use of APPLY, easy access has been obtained to standard programs on Atlas, such as the Laboratory's information retrieval system.

The decision to provide detailed error diagnostics throughout has meant that a lot of storage space has had to be given over to the text of these messages. Nevertheless, with the added assistance of most of the write-up being available on-line by means of the pseudo-command /HELP, it has been found that newcomers to the system - even newcomers to computers - have become conversant with most of the facilities offered in a remarkably short time.

INITIATION OF ATLAS JOBS

Access to Atlas was necessarily restricted by the Atlas operating system [2]. Input files had to be copied into a form suitable for reading as private input documents. Yet this too has had advantages, since there is no restriction on their further use after the job has been initiated, and no problem associated with the provision of lock-out bits has arisen for preventing possible simultaneous use of files by Sigma and Atlas. Data returning to the file system has to be similarly translated from Atlas output form into a file. Such data is appended to the file if it exists, or, if not, a new file is created with free status (i.e. the user has unrestricted access), but using permanent space to avoid the possibility of the file being deleted by the system before the user has had a chance to see it (he might have run the job producing the file just before a month's holiday).

The job description [3] file for a job initiated in this way is sent across the paper tape reader/punch channel, and relatively few checks are carried out on it. No check is made for spurious job terminators in this file, however, and it is unfortunately possible for a user to effectively disable this link by erroneously including a marker (***B) requesting the system to continue reading in binary from this file! Checks would of course have to be included for this in a more open environment.

The decision not to build elaborate software checks into the job description decoder has enabled the management of the use of Atlas via the multi-access system to be controlled in a simple but powerful way. Users are made aware of the limitations on jobs initiated at different times of the day and over-all enforcement of these limitations has been made retrospectively by verbally warning offenders. This has proved sufficient in practice, but management can exercise the option of completely preventing one user running jobs in this way if he persistently ignores the limits and warnings. Special arrangements can then be made for abnormal jobs without invoking the system software either by programming or by operator action.

STORE MANAGEMENT

Since no backing store device was originally available to assist with extra storage (apart from the file system), the system as designed has proved very effective. Each user has a one-line buffer for teletype input, which is subsequently copied into a small buffer (196 characters). Small buffers are chained together to hold data until either there are no more buffers available, or the user has finished typing. A disk buffer is then obtained, the contents of the chain copied into it, and the data written to disk. (Disk buffers are 1½ K 16-bit words long, made necessary by the disk being shared with Atlas and divided into Atlas blocks, which hold 512 words of 48 bits.) The chain of small buffers and the disk buffer are then released. In this way, large storage buffers are held for the minimum period possible. However, with the subsequent provision of the fixed head disk any redesigned system would include some form of paging or segmentation of perhaps both code and free store. Unfortunately, the original design meant that the inclusion of any such scheme for free store would entail a major rewrite, albeit of only the store section of code, and any attempt to page the code would prove even more difficult. This is a direct result of the original designers not taking into account the possibility of acquiring extra backing store.

A two-queue system has been used to control disk accesses. The first queue controls the allocation of disk buffers, and the second controls the transfer itself. A user requiring to read a disk block will normally need to obtain a buffer as well, and if this necessitates waiting on the buffer queue, the transfer subsequently requested for that block is promoted to the head of the second queue. Otherwise, both queues are organized on a first come, first served basis.

This system has worked well, but simulation has shown that the' introduction of the idea of positive and negative direction on the disk and the selection of the transfer which requires the nearest block in the current direction would speed up this queue.

SYSTEM CONTROL

The control of the system by operator requests has grown up rather haphazardly, especial1y in the way output messages are put together. However, it was made sufficiently general to enable these requests to be entered from any peripheral (other than user terminals), and all messages to be output similarly to any device. Thus the system is not totally dependent on the control console for its operation.

In addition to the broadcast feature, which occurs in most systems, we have found a one line message of the day facility (printed as each user logs in) and a news file (for storing larger amounts of information) to be of great use. Also the presence of a user command for determining which users are logged in to the system has also been useful when attempting to gauge the likely system response to expensive operations.

Although the software-controlled statistical clocks (a method of counting time-dependent events) take up rather a lot of space, they have proved very flexible in use and have enabled the collection of quite intimate statistics for a mathematical model, [4] as well as providing information on numbers of disk transfers and timing out sleeping users. A user who leaves his terminal unattended (i.e. has gone to sleep) is eventually thrown off (after five minutes) so that his line may be used by another. This has the additional security advantage that someone else subsequently trying to use this terminal does not find himself logged in under another user's number and with access to his files.

The inclusion of a software trace greatly assisted in debugging the system. A record is kept of the last ten exits from the idle loop, giving details of which user was involved and which routine was entered. Thus, when the system crashed, it was possible to sort out who was doing what. The overhead involved is so small that it was decided to leave the trace in the system as a permanent feature and hence the small number of errors which turned up later in the life of the system were relatively easy to diagnose.

Although intended for only in-house use, the system has been made available to certain external users. Initially one manual modem was installed. However, although it is easy enough to connect a user, there are a number of problems associated with his disconnection. If the caller cuts the call, some means must be found of informing the operator so that the manual line may be cleared. Of course, the computer can type a message to the operator when a manual user logs off, but this does not get over the problem of a caller getting a bad line at the start and wanting to try again. A slave console was finally installed so that these conditions could be monitored, detected and rectified by the operator. It was also found necessary to provide a line to this modem which the external user could dial direct without involving a telephone operator, and to guarantee the user entry to the system once he had acquired the telephone line. When automatic modems were attached as well, it was even more essential that directly diallable lines be used, but then no guarantee of entry was given, since operator intervention is not required, and the computer can detect the state of the modem and cancel the call. However, an extra time limit had to be imposed between the connection of the line and the receipt of the log-in character to prevent the modem being locked out by a caller dialling the number and then cutting the call (as for a wrong number). In this case, it is possible for there to be sufficient noise on the line for the computer to continue to detect carrier signals from the now clear line.

THE USE OF ATLAS

The availability of the large computer went a long way towards helping to write the system in so short a space of time (ten months or so). Indeed one could almost say that the paucity of manufacturer's software on the satellite at that time was an advantage, since there was no temptation to make do with a restricted assembly system or even to fit the multi-access system into an existing monitor which was not designed for the job. It was a pity, though, that the decision was nevertheless made to implement the existing assembly language and write the system in that. The arguments for using high-level languages for operating systems are well known but at the time there was no manpower available to implement both a language and a system. Although some work has been done in this area, the efforts so far appear either to be designed for large computers or else are highly dependent on the idiosyncracies of the particular small machine for which they were written.

DOCUMENTATION

Another problem which rarely receives adequate attention in designing a system is the provision of satisfactory documentation at all levels. It is often the case that the only documents available at the end of a project are a user manual and a general description. During development of the Chilton system, two series of papers were issued. One provided minutes of meetings held with manufacturers - essential when the hardware connection involves six different groups of people. The other gave a means of documenting ideas as they occurred. This not only ensured that such ideas were properly formulated, but also prompted constructive criticism from other members of the Laboratory not directly involved in the project. In addition, it prevented repetition at a later date of some train of thought which had proved abortive. The code, of course, was heavily commented, and written descriptions of entries in the numerous tables were kept. A complete list of routine specifications, giving details of input and output parameters and registers changed, and a concordance were also provided. Finally, as well as the two usual documents, a third series of papers gave detailed technical descriptions of various well-defined areas, such as the control of the Atlas link, and these areas were also flowcharted.

THE REPLACEMENT OF ATLAS

As most of the system resides in the satellite computer, it is theoretically possible to replace Atlas by another large computer, retaining the same multi-access system and only altering the satellite code for the RUN and SUBMIT commands. However, in practice, there are a number of problems. In order to allow sufficient volume of data to be sent with each job, it is a great advantage to retain the triangular arrangement of satellite-disk-computer. If only a satellite-computer link is available, the link may soon become congested and considerable work is required to determine the speed of link necessary to avoid this congestion. The disk that was used had a maximum transfer rate of 6M bits per second, although the average rate was more like 200K bits per second, so a link of similar speed would be required to maintain the current response times.

Most large computers now provide both their own file system and their own multi-access system. It would seem pointless, therefore, to provide a second distinct file system, so the triangular arrangement would need to contain a disk (or similar device) which was already part of the main computer's file store. This could be considered as a satellite-file store-computer link, which would entail a major change to the existing system. The only point in providing a second multi-access system seems to be if the existing one overloads the machine too heavily with its control software. Rumour has it that such systems do still exist!

Sigma 2 as Remote Entry Test System after Atlas Closure

Sigma 2 as Remote Entry Test System after Atlas Closure
Full image ⇗
© UKRI Science and Technology Facilities Council

THE USEFULNESS OF THIS APPROACH

The general idea of hiving off the file handling and editing sections of multi-access does seem to be worthwhile. If the general principle is followed throughout, it should be easily possible to upgrade a whole computer system by parts, without the need to rewrite great sections of code. The dedication of the main machine to batch work should be very useful in a commercial or service environment, where the multi-access aspect takes a secondary place. The extra cost of hardware should be more than offset by the gain in efficiency and speed of throughput.

REFERENCES

[1] J. C. Baldwin and R. E. Thomas, Multi-access on the Chilton Atlas, Computer Journal 14,119-122 (1971).

[2] T.Kilburn, D. J. Howarth, R. B. Payne and F. H. Sumner, The Manchester University operating system. Part I, Computer Journal 4, 222-225 (1961).

[3] D. J. Howarth, R. B. Payne and F. H. Sumner, The Manchester University operating system. Part II, Computer Journal 4, 226-229 (1961).

[4] R. E. Thomas and P. Kent, Control of queues in a permissive society, Software - Practice and Experience, 2, 79-'91 (1972).

⇑ Top of page
© Chilton Computing and UKRI Science and Technology Facilities Council webmaster@chilton-computing.org.uk
Our thanks to UKRI Science and Technology Facilities Council for hosting this site