It is not pertinent to discuss here details of the file dictionary; all we need to assume is that any user (including the supervisor) can create and access files by name. Similarly the details of disc allocation need not be considered. The file system does however occupy a central place in the I/O scheme, in that it is taken as a principle that as little material as possible should reside on the disc which is unknown to the file system, i.e. cannot be accessed via the file dictionaries. This principle is adopted in the interest of generality; it does not preclude the provision of short cuts for the supervisor to use to access, for example, parts of itself.
It is arranged that unless a file is active, i.e. it can be read from or written to by an object program without further administrative manoeuvres, no information is held in core about it at all. This point seems almost too truistic to mention - except that the ICT supervisor is not like this, which constitutes one of the limitations on it. When a file is made active, various relevant details are extracted from the dictionary and copied into temporary base in core, where it remains as long as the file is in use. Since these temporary bases are handled by the general space-routine mechanisms, there is no arbitrary limit on the number of active files a program can have. This working information is put together either when a program explicitly calls for it, or, should the necessary details have been put in a Job Description, immediately before the program is first activated. The function of the JD, therefore, becomes to a considerable extent that of allowing the programmer to indicate certain administrative routines which he would like to be obeyed before his job is started. For historical reasons this is unlikely to be an accurate description of the way the JD is used, but it is a useful way of looking at the matter.
Most of the foregoing is applicable to files of all sorts, but it is hardly possible to go any further without introducing a distinction between files which are to be treated as (in any sense) character streams, and files which are to be treated as straightforward blocks of words with no interior structure, transferred to the user's core as such. In a system where the supervisor does very little about character handling and stream processing, all bufferage being provided by the user at his own expense with the aid of library routines, it is possible to suppress this distinction completely at the system level. For us this is undesirable because of the extensive work done by the I/O extracodes automatically (and very conveniently) and because of the existence and general utility of the backing-store block transfer extracodes. We therefore say that when a file is active it is either in a character-stream mode or in a block-transfer mode, but never in a mixture of both. It must be emphasised, though, that there is no distinction as far as the dictionary or the file-system itself is concerned. A file may be written as characters and read as blocks, or vice versa.
The most basic operation is to set up a correspondence between one of an object program's 16 logical input streams and some stored character stream in the filing system. In order to explain how this can be done, we need first to look at the treatment of ordinary slow peripheral input streams, i.e. documents put in at tape - or card - readers, associated with a program by means of a job description. We have adopted two views:
Accordingly it is arranged that all peripheral input passes initially to the file, using a file dictionary belonging to the system, and names made by the system which will enable it to recover the logical number of the job (its 'cipher') and its stream number from the user's view. This latter is determined from the job description in the case of an ordinary job and by convention in the case of an on-line job.
It is now relatively easy to describe the way in which filed material is connected up with a program's input stream. The program gives the input stream number for which it wants the connection made, together with the name of the file. If the name of the file is omitted, the supervisor's file dictionary is searched for an input document with the appropriate job number and stream number. In either case the program is faulted if the sought file is not present. If it is present, the short abstract of details mentioned above is constructed and chained to the appropriate place. The stream is then ready to be selected and read.
In either case a file may be re-read at any time if desired. If the 'create input stream' routine which connects the stream to the file is re-entered, the old records are thrown away and the stream re-set up at the beginning.
Output streams are handled in a very similar way. The connection may be made between a program's output stream and either one of the user's named files or one of the supervisor's output files. There are two slight differences from the input case.
The situation is slightly more complicated here because it is desirable to preserve reasonable compatibility with the use of private magnetic tapes. It will be common for program development to be done using the filing system with block files and to transfer subsequently to private tapes where large storage is needed. It should not be necessary to change the programs much or at all at this point.
As with character stream files, the basic approach is to correspondence between logical backing store numbers (as used in backing-store extracodes) and either named files on the filing system or specified parts of named private tapes.
The restriction placed on block files is that they must consist of a compact sequence of numbered blocks starting at 1. That is to say, if a particular file has at present 57 blocks, I can
The basic administrative operation is 'Create backing-store device n as the file named NAME', and analogously for private tapes, 'Create backing-store device n as the tape named NAME starting at physical block m'.
The standard way to effect this latter operation is via the job description, as it is likely to involve a long delay. Just as in the case of stream files, the setting up operation creates a small note of file details to be referred to while the file is active. To give full flexibility to the user, the restriction of compactness of files applies only to use of the filing system and not to files on private tapes. Object program faults due to violating compactness restrictions are detected in a routine for correcting a logical block address to a physical block address: and this need not be entered for tapes.
RMN
22 June 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.
Previous Planning Document: 1. The Proposed TITAN
'Disc' Supervisor, DFH, 25 May 1965
Next Planning Document: 3. (Untitled: preliminary to
number 4), RMN, 29 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