ATLAS is a multiprocessing computer system. The operating system was designed to keep the central computer as busy as possible, and to achieve this it was necessary to divorce the user from the computer and let a resident program, the Supervisor, decide how the central processor should be deployed.
The objective of the Supervisor is, of course, to get the maximum number of object programs done. Input and output proceed while computing is going on but at a very much slower rate, so it is essential that they are buffered. Programs and data coming into Atlas are collected on a magnetic tape, the input well, by a system where the program running is hesitated for very short periods while the Supervisor deals with characters from input peripherals. These interruptions are irrelevant, of course, to the program running. Complete jobs in the input well waiting to be run are ordered into one of three queues. These queues are for jobs which use magnetic tapes, long jobs, and short jobs.
The Supervisor tries to keep three jobs in the central machine for execution, one of each type. Only one of these at any instant will be computing, but when it is held up, for example by requesting a magnetic tape transfer, then the Supervisor switches control to another job after initiating the required transfer, to avoid wasting any precious computing time. Program output is not sent straight to the output peripherals but buffered in the store and then on to a magnetic tape, the output well. When the job ends, then its output is allocated to the least busy of the peripheral type it requires and output proceeds on an interrupt system as described above for input.
Essentially, then, input and output are external to a job's execution and the central machine works on one job until the job gets held up, whereupon it switches to the next job which is free to compute. A staggeringly large number of programs get run daily by Atlas, and there is no doubt that the computer is efficiently utilised. This is just as well, because the machine is overloaded with work. If the Laboratory accepted every project needing computing, then ten Atlases might be needed to give an acceptable service.
However, it is also clear that many users are being utilised inefficiently because of this method of computing. In the early days of computers, users booked time in advance, and usually turned up in person to sit at the machine control desk. This used the machine inefficiently, but the user could do things he is not now allowed to. Let us take an example to consider the different procedures. Say I have written a new program to calculate some function. In the old days the following might have happened during my period on the computer:
The numbers in square brackets show how many separate runs on Atlas might be needed to get as far. If I use the postal service then my turn-round time for each run is likely to be three days, so it has taken over two weeks on Atlas to do something that would have taken me less than half an hour ten years ago. Even if I am in the Atlas Laboratory, it might take me two days. Each time my output comes back from Atlas I have to recollect what was happening and reconsider the problem, i. e. I am duplicating my own thinking. Further, because of the long turnaround time and the limitation that I can only take one step forward at a time, I might be developing several independent programs in parallel, instead concentrating my energies on one.
The problem of using the user more efficiently has been tackled vigorously, and project MAC at M.I.T. is responsible for the first working computer system [1] which allows users to think they have the machine to themselves. The outlines of this system, and of the many which are based on it, is as follows. Jobs may be 'background' or 'foreground'. The former are run in a normal multiprocessing mode as described above. Foreground, or 'on-line' jobs, are run under the direct control of users. Each on-line user has a teletypewriter, or some other peripheral, which can be used for both input and output. The computer allocates a short time slice to each active on-line user in turn. His teletypewriter gives him direct input/output to and from his program running on the machine, and apparent control over what happens.
The system provides a command language for users to specify what they want to do, and a comprehensive filing system to maintain programs and data within the machine. These documents in the filing system are recognised by a unique name; this might specify the user's name for it, the type of document and whether it can be used by anyone other than the owner.
The work done in our example might be achieved in a single short session on a time-sharing machine. The user would 'log in' from his teletypewriter terminal and then type in various commands to the system. Assuming that his program had been filed under the name of, say, DELTA, then a command of the form FORTRAN DELTA would result in the Fortran compiler being applied to this document. Errors found by the compiler would be listed and corrections for the incorrect statements would be typed in by further commands. After correctly compiling, the resultant document could be loaded and run with data also typed in. The dialogue might be something like that shown below. The users statements are shown in small letters, the replies in capitals; in practice, different colours might be used.
login baylis 103 BAYLIS 103 LOGGED IN. DATE 24.8.66, TIME 14.31. 07 autocode (delta, delta 1) COMPILATION FAILS LINE 51 ERROR 3 WRONG FORMAT X = SIN(Y + B(I, J) LINE 92 ERROR 1 LABE L NOT SET GO TO ZETA edit delta verify find (line 51) X = SIN(Y + B(I, J) replace. ) . )). X = SIN (Y + B(I, J)) find. print (tiger). PRINT (TIGER), FORM (7,1) replace. P. ZET A)P. ZETA)PRINT(TIGER), FORM (7,1) autocode (delta, delta 1) FILE DELTA 1 DEFINED BY AUTOCODE DELTA STORE REQUIRED = 880, PARAMETER SPACE = 65 run delta 1 X = 15.1 N = 3 TIGER = stop . .. and so on . . .
At various times, particularly when compiling is asked for, there may be a considerable period before the computer responds. If the compiling takes 2 seconds, say, and there are thirty other active users it may be a minute or so before the results get printed out and further input can be made.
It will be at once apparent that a time-sharing system is splendid for the user. However, like all good things, it has to be paid for; the present payment on all existing systems is an enormous loss in machine efficiency For example, on the project MAC 7094 computer - which is at least half an Atlas - background working has been abandoned and the machine can be saturated by twenty users. Admittedly this project was purely experimental; the next machine, a GE 645, has been designed to improve the situation. The facts remain that no system has been designed yet to do both background and foreground work efficiently.
All of this has been a preamble to a problem that has been facing us for a while. That is, how to provide some valuable time-sharing facility on Atlas without ruining the throughput figures. The case against having time-sharing on Atlas is as follows. The whole operating philosophy is against it. Direct input/output to and from a program is not allowed. Program changing is a costly business so is kept to a minimum. Peripherals which look like both input and output media were not envisaged, and are expensive to add. It is difficult to alter the Supervisor program, partly because eight thousand words of it are semi-permanent in a fixed store. The case for having time-sharing is as follows. Users will benefit at least from the editing facilities. By keeping documents within the machine the amount of input and output will be reduced, possibly by a large figure. Some potential users for whom the machine has been oppressively inconvenient will be encouraged. The increase in users efficiency must result in a higher level of productivity. Opportunities will be created for applications as yet unthought of. Insight will be gained into the time-sharing problems which should help in the choice of future computer systems. In some respects Atlas is ideal; there is a sophisticated store management system, a large virtual memory, good interrupt facilities; Atlas is a very fast and reliable computer. Users want it.
The remainder of this paper outlines how we will provide a time-sharing system which we hope is almost open-ended; that is, it can be extended a long way by adding more equipment and taking more time from background work.
The filing system will be implemented with a 16½ million word (48 bits) disc file with a dual access mechanism. A part of this disc will be used to replace the input/output magnetic tapes. A further part will be available for conventional users. This part may be used instead of free magnetic tapes or just as scratchpad area. The majority of the disc will be used for the filing system. This will be backed up by archive magnetic tapes and incremental dumping/retrieving to and from tapes will be an automatic procedure. The disc can be extended to 30M words if this becomes desirable.
On-line terminals will be attached not to Atlas but to a small satellite computer. Initially about twelve teletypewriters will be provided. We have looked into the possibility of attaching cheap visual display units with keyboards. These, even with characters only, are in our opinion much superior to typewriters but they are unobtainable as yet in Britain. However, if they do become available they will certainly be attached. The number of terminals provided will depend on the use made of them and, of course, on how many the system can handle.
The satellite will be attached to Atlas in two ways. It will have the other access channel to the Atlas disc, and both machines can be doing disc transfers simultaneously. Both machines will be connected to look like peripherals to each other. This gives core-store to core-store transfers at a variable rate determined by the activity on the machines.
Overall control of the terminals, and in fact of the time-sharing system, will be from the satellite. The command language, editing program, file management scheme etc. will all be implemented in the satellite. This means that a considerable amount of work can be done without involving Atlas. When Atlas is required to do some computing then, in general, the peripheral link will say what needs doing, for whom, and where the information is on the disc. Time-sharing on Atlas will be under the control of an 'on-line Supervisor'. This will be written as a privileged object program. We now envisage four types of job; magnetic tape, long, short and on-line. If any of the latter exist then the on-line supervisor is activated. It will arrange time slices on Atlas on a parametric basis, knowing how much percentage of Atlas time is to be allocated for time-sharing, how much store it can have, etc.. Interaction between jobs running on Atlas and their consoles is a feature of the scheme; for this the satellite simply acts as a message handling device, i.e. as a postman. It is also intended that many things that can be done from a console can be done by a background job. Thus non-time-sharing jobs will be able to manipulate files, create, rename, edit them and so on. They will appear to the satellite as pseudo-consoles of low priority.
A discussion of the satellite configuration, expected response time, scheduling algorithms, throughput degradation etc. is outside the scope of this paper.
Within the Laboratory, many projects hope to flourish in a time-sharing environment. Some of these are mentioned in this document; they include artificial intelligence studies and gaming problems, information retrieval, algebraic manipulation, statistical analysis and real time decision studies. Users who are pressing for time-sharing facilities are too numerous to list. Their interests range from high energy physics to brain damage studies.
[1] The Compatible Time-sharing System by F.J. Corbato et al, M.l. T. 1963.
