This document sets out to do three things. Firstly, to describe in general terms the philosophy of the Disc Supervisor giving the major differences from the ICT Atlas 2 Supervisor. Secondly, to indicate some of the work involved; and finally, to propose the basis of a working schedule.
All planning stems naturally from the ICT Atlas 2 Supervisor currently being implemented for Aldermaston. With this as a basis, there are the following criteria:
The system as planned is in no way "final". The aim is to provide a basic system enabling further development both for improved efficiency and for on-line operation, but which is complete in itself and capable of maintaining a computing service (the facilities and capacity should be better for our purposes than those of the Atlas 2 Supervisor).
The main influence of the disc store is to provide an alternative approach to the problems of transferring input material from backing store to object programs. The Atlas 2 Supervisor places much emphasis on sophisticated scheduling from magnetic tapes. Instead, it is intended that input material for object programs is collected on the disc and brought to core on an "on demand" basis as required by input extracodes. The amount of core space for input stream buffering will still be organized in a flexible manner, but the mechanism is substantially simpler. This approach becomes possible when one relies on multiprogramming to absorb disc search and latency periods.
Material on the disc is divided into four categories:
Although we have chosen to indicate the categories, it will be seen that this does not necessarily mean that the implementations are wholly different.
Documents of categories (a) and (b) are recorded in the same format and are transferred to and from core store by the same routines. The essential difference is in the way they are identified, not in the way they are handled. Items of category (c) may include material dumped from large core areas (e.g. object programs) and can also be organized by a common set of routines. Category (d) presents no problems since transfers are essentially under direct control of object programs.
The allocation of space on the disc for all items of categories (a), (b) and (d), and possibly for certain of (c), is organized by a single set of routines. It is proposed that the basic unit (or element) of space on the disc should be 2 blocks (≡ 1024 words ≡ 8000 characters). A document on the disc will be contained in one or more such elements; normally these will be scattered and thus elements must be chained. However, straightforward chaining in the information has the disadvantage that to delete a document from the Well or the Main Users' File requires the document to be read from the disc. Instead it is proposed to keep the chains in a special map: this map is conveniently organized as four 512-word blocks, normally held on the "fixed head" disc, and each individually retrieved to core store as required. The map is also used to organize free elements and will also enable the allocation of consecutive disc elements when necessary. A further advantage of keeping the chains separate from the information is to permit easier dumping of binary material from core store.
Sophisticated scheduling of input material from the Well to core forms the basis of job scheduling in the Atlas 2 Supervisor which does not, of course, provide multiprogramming. In the Disc Supervisor it is therefore possible to make object program core space the basic criterian for job scheduling, and this is essential for effective multiprogramming. Changing the Well organization to an "on-demand" system also enables a simplification in the administration of input/output streams, which in turn has the following advantages:
Finally, to make the system itself readily expandable, either in its basic Supervisory facilities, or, more important, in its Operating System characteristics (e.g. developing an on-line system, plugging-in compilers etc.) a new form of Special Object Program is proposed. This facility essentially enables routines of the Supervisor to be run as though they were object programs with the following advantages:
The Coordinator (which organizes the sequencing and queuing of Supervisor activities) needs a few changes. The mechanism to provide multiprogramming is already present and will only require slight modification. Extra facilities must be provided to handle Special Object Programs, but the work involved will be small.
The Central Space Routines require modification to enable multiprogramming and certain other facilities. Space allocation for object programs (and compilers) is largely a job scheduling matter, so that the Central Space Routines need extending only to administrate object program space. Space scheduling will thus be made a separate item to permit easy development in the future. Changes to existing routines can probably be limited to re-writing one routine only.
The Retriever (which organizes the transfer of Supervisor Chapters and compilers from backing store) needs minimal alterations in consequence of the library being held on the disc. It is possible that this routine might be extended to handle the dumping and undumping of object program core areas.
There are two substantial items associated with the disc:
Disc Basic Control and Disc Well.
The Disc Basic Control routines provide the mechanism for all disc operations, including error detection facilities. Interface with the rest of the Supervisor will be as near as possible to the existing magnetic-tape control routines. Not only will this have obvious advantages for other routines which have to be converted from using tape to using disc, but will enable simulated testing of the Disc Well and other routines before the hardware is ready. David Wheeler is writing the Disc Basic Control, and the job is virtually self-contained.
Primarily, the Disc Well consists of routines for organizing the transfer of input/output material between disc and core store. The name is not exactly correct since the same routines will also handle documents to and from the Main Users' File. The Disc Well (in common with the existing Tape Well) takes advantage of the ability to transfer information between scattered blocklets (64-word sections) in core store, and therefore interfaces conveniently and efficiently with the Central Space Routines. At the same time, however, when core space permits, the routines attempt to arrange for transfers of units up to 1024 words at a time to improve disc efficiency. Once the Disc Well routines have been written it will be possible to combine them with the Tape Well routines to form a composite Well system. This combination need not be determined until practical experience has been obtained, and it will be feasible to begin with a simple system: for example, all documents destined for output peripherals using the Tape Well, and all other documents using the Disc Well (or Main Users' File) and perhaps additionally, input documents from peripherals also being copied to the Tape Well as a safety measure to permit easy restart in the event of machine failure.
The Disc Allocation routines are planned in conjunction with the Disc Well, but will be self-contained and capable of independent implementation. Their job is to organize the allocation and chaining of 1024 word elements of disc storage, and also to provide consecutive elements for dump purposes.
Most of the work concerned with the Main Users' File is provided by the Disc Well. There only remain the problems of initiating file transfers and deletions, and of dictionary administration. The former will be provided by the Job Organizational routines, while the latter might be provided in a flexible and readily expandable manner through the medium of Special Object Programs.
The existing mechanism for establishing and controlling object program input/output streams is not entirely satisfactory, mainly due to the Tape Well scheduling system. To provide a better system, the input/output Extracodes are to be modified to operate in the following manner. Whenever a new blocklet (≡ about 500 characters) of core buffer is required a subroutine is selected and entered. The action of this subroutine is determined by the type and status of the stream's source/ destination, thus making new data routes relatively simple to incorporate.
A consequence of this change will be to enable new Extracodes for creating input/output streams to be provided, and also the direct data routes between object program and on-line console to be established. In their turn, these features will improve compiler administration and on-line system development.
To enable multiprogramming some form of job scheduling is required to allocate core space, priorities etc. Initially this may be reasonably crude; implementation as a Special Object Program will permit easy development of more sophisticated algorithms later.
I do not consider it wise, nor myself capable of attempting to estimate the amount of effort required for the individual parts of the project at this stage. However, it is becoming clear how, and in what order the various items should proceed.
There will be an initial stage of detailed planning and coding the more substantial items. Barry Landy has already started this for the Disc Well. Very soon work will also begin on extending the Central Routines, the Disc Allocation Routine and changes to the input/output Extracodes. All these will be tested individually, and possibly put together as a complete system with disc/tape simulation routines if the disc hardware and software is not complete by this time. Disc Basic Control should proceed in parallel with this activity.
Work on the machine will use the existing TSAS/TSDS systems with files on magnetic tape; the small size of the Supervisor Group should enable these files to be kept under some sort of control to reduce the amount of tape searching time. However, once the disc hardware is sufficiently reliable it is hoped to incorporate a simple (non-timesharing) disc transfer routine in TSAS, so that by using the disc as a file, we shall benefit from better machine usage, and the engineers should benefit from the hardware being used.
The next stage would be to improve the job organization routines, to provide a file dictionary system and to write the first job scheduling algorithm. Also at about this time we should be in a position to receive and incorporate new items and improved versions of existing items currently being prepared by ICT for the Aldermaston machine. All together, we shall then have a complete system (including a Users' File) which should be capable of supporting a substantial computing service. Enough compiler interface will be present to plug in both Titan Autocode and Fortran.
The next logical step is then to produce routines for controlling the Teletype keyboards and for establishing the direct routes between them and object programs. Much of the work can of course proceed in parallel with earlier items, but this would be the correct point for "plugging-in". We should then have a system under which further work (both for maintenance and for development of an on-line system) can proceed in parallel with an adequate computing service system.
25 May 1965
Copyright © 1965 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.
Next Planning Document: 2. Some notes on the general
characteristics of the proposed I/O system, RMN, 22 June 1965
Return to Cambridge Supervisor Planning Documents
Return to CUCPS TITAN page
Return to CUCPS home page
Return to University of Cambridge home page