This document describes the organizational and usage features of the planned filing system. The basis of this was laid out in Planning Document 11.
A file is any document that is known to the system through an entry in the file directory. It is not necessary for a file to be associated with a particular disc position or indeed with a particular storage device. There may be more than one copy of a file in existence at any one time.
If a file is altered it is treated like a new file with the same name as an old and now non-existent file. No attempt is made by the system to maintain any record of the old versions of a file.
An object program will always use a file as if it were always held on disc. However, because of pressure for disc space, certain files will be held on magnetic tape when not in use. Details of the mechanisms for loading and unloading these are given below.
The title of a file is written as
A / B / C
where the components A, B and C are each limited to 8 characters
Component A is the name of the owner in the form: initial followed by job number.
Components B and C are chosen by the user. The title may only contain the following characters:
| letters |
| digits |
| + - . |
| Space |
Each component is filled with shift characters (0.5) at the least significant end to bring the length up to 8 characters.
The file status exists to control the way in which the file is used and to influence the assignment of the file to storage space on disc or magnetic tape.
The status is specified in two parts by the user when he creates the file.
The file usage specifies the extent to which the file may be made available for subsequent processing. It places limits on the types of permitted activity as well as the permitted users.
The limit on type of activity is specified by a single letter for each of the four recognized types of user. The letters are:
| R | Can be Read but not altered in any way. |
| D | Can be Read or explicitly deleted but not updated. |
| U | Can be Read,deleted and updated and, if a new file with the same name is created, then the current version can be deleted automatically. |
| N | Cannot be used at all. |
| F | Free to be used for any operation which includes changing the status of the file itself. |
The four types of user are:
The usage is specified for each of these in the order given so that, for example, the usage FURN dictates that the owner can do anything he likes with the file, a part owner can read, delete or update the file, a key holder can only read it, and other users may not have access to the file.
File Class influences the allocation of disc space and magnetic tape space to the file. The normally available class types are:
| W | A working file to be held on disc and also to be preserved on archive magnetic tapes to guard against accidental loss. |
| T | A temporary file to be held on disc but not to be preserved on archives. |
| A | An archive file that is to be held only on archive magnetic tapes. |
Two further class types are recognized, both of which are treated for many purposes like class W.
| P | A working file that is nominated as the 'preferred' version of a set of similar files all of which have the same title components A and B. If a user asks for a file with the title A/B/* then he will be given the preferred version if one exists. If no preferred version exists then he will be given access to an arbitrary member of the set of files. |
| S | A system facility file. This class designation is not available to the normal user. It is used for the current working version of a file that is essentially part of the Titan software complex. |
The first component of the job title is taken to be the name of the the user. This user owns all the files which have this name as the first component.
Each file owner may specify a series of names of users each of which is to be regarded as a part owner of his files. If file owner H specifies that users W and V are part owners of his files then W will be allowed access to any file H/X/Y provided that the second letter in the usage for H/X/Y indicates that the requested activity is permitted for part owners.
The owner, H, may impose two further restrictions on each part owner separately.
If a part owner has status F, he is allowed to create new files on behalf of the true owner. No other person is given this privilege.
Associated with each file owner is a 'key' which is a series of 8 characters. This key can be changed at any time by the owner and no other person may either inspect or alter the key.
Any user who can quote the key for a particular file owner becomes a key holder and as such may have access to any file owned by that file owner. In the capacity of key holder his activities are restricted separately for each file by the third usage letter in the file status.
The 1026 extracode is used with n = 2.4 by anyone who considers that he knows another persons key.
It is essential to the success of the system that the user should be able to rely upon the security provided against accidental loss. Protection is automatically given, therefore, to all files in classes S, P, W and A. This protection involves copying the file onto magnetic tape and later duplicating this tape. Thereafter, two separate copies of the file are held until the file is deleted by the user.
In the first instance, output will be onto a set of system 'dump' tapes which will be updated regularly (about 2 or 3 times per hour). At regular intervals (about 1 week) the dump tapes will be used to update a set of 'archive' tapes that each contain the currently valid files for a number of users.
It is to be expected that disc space will be in demand and that some system of space control will be necessary.
Normally all Class A files will be off-loaded onto magnetic tape as soon as possible after they are created. If this action does not produce enough space all the Class W, P and T files for selected users will be off-loaded. The user affected in this way will be chosen in strict rotation.
Disc space will be rationed and a maximum disc space allocation will be given to each user, This will specify three values:
When a file is closed, the system will check that the total space used by all files in the chosen space classification does not exceed the limit set by the administration. If the limit is exceeded than the file may be thrown away by the system. To minimize the inconvenience caused by this action, the class of the file will first be changed to T and a second attempt will be made to file it. If the second attemtp fails, the file will be lost.
The total volume of data held on archive magnetic tapes will be checked regularly and users will be notified if they have exceeded the limit laid down by the administration.
A user can normally expect to find all of his files on disc except those in class A.
If a class A file is required or if another file, which for some reason has been off-loaded, is required then a "file recovery request" must be made.
These requests are queued by the system and are processed in bulk at regular intervals. When a file is recovered it is transferred from magnetic tape onto disc in the form in which it was last dumped. The class designation for files of class A will be changed to T but for other files the class will remain unchanged.
The queue of recovery requests is updated by the system program ADFILE, a description of which is given below.
For the off-line user, ADFILE may be used as the first phase of his job. When handled in this way, the job will be run immediately only if all the files required are loaded. If any file is found not to be loaded then a file recovery request will be made. When the last file recovery request for a particular job has been processed by the recovery program the operator will be given a second opportunity to run the job.
For the on-line user ADFILE may be used to make file recovery requests which are accompanied by a message. This message is sent to the operator when the last file has been recovered and could, for example, say "RING AGF on EXTN.38. FILES RECOVERED".
Care must be taken to avoid making an abortive recovery request which arises when the disc space limit is reached.
The file title is written as 3 components separated by solidus. In the job description the title is enclosed in parenthesis and in the extracodes which involve file titles it is terminated by an extra solidus or by the character 0.0. In either case, the title is terminated at the 24th character. If either of the components B and C is omitted, it is replaced by one consisting entirely of shift characters. If component A is omitted then the first component in the job title is substituted.
Component C may be an asterisk only when making a request for a file that already exists. It is assumed that this component will contain the version name for a file and asterisk is used to specify 'any' version. If there is a version with class = P or S then that is chosen.
The file status must be specified for newly created files and it is written as if it were a fourth component in the file title. The usage is written first followed by the class and the latter is identified by a preceding decimal point. Not all characters in the status need be specified. Right-hand characters in the usage may be omitted and either usage or status may be omitted entirely. The default value for status is
FNNN.T
When file/status is specified in a job description or extracode, the total number of characters must not exceed 28.
(Note: The specification for the system program ADFILE is given in order to show which facilities are needed. It is probable that those will be incorporated in a more general command program which is available to both the on-line and off-line user.)
The commands recognized by ADFILE are listed.
Check that the file named is loaded. If not, store a request for re-loading.
If the title has the form A/* then check and, if necessary, re-load all files belonging to A which have class = S, P or W.
Ignore this command if all files specified with USE commands are found to be loaded. Otherwise, file the message with the file recovery requests so that the message is sent to the operator when all the requests have been satisfied.
Ignore this command if any file that is specified in USE is found to be not on disc. Otherwise, change phase into the job specified when all commands have been processed.
Change the status of the named file to the new value given.
Delete the named file. If the title has the form A/B/* then delete all the files in the set A/B.
If the named file is class T then delete it, otherwise do nothing. If the title is of the form A/B/* then delete all class T files of the set.
If the title is of the form A/* list all files owned by A. If A/B/* then list all files in the set A/B. The privilege required to list another persons files is given only to part owners with status F.
As for LIST but only recognizing class T files.
The title must have the form A/B/C. The specified file is changed to status P and all existing files in the set A/B which have status P are set with status W.
Force a file to be unloaded from disc after ensuring that it is preserved on magnetic tape.
Attempt to declare the current user as a key holder far the named file owner's files.
This command can only be used by a file owner. It has the effect of changing his key.
The input section normally includes lines of the form:
<stream number> (<document title>)
To set up a stream from the data held in a filed document write:
<stream number> FROM FILE (<title>)
The file may be any one that the user is allowed to read.
The output section normally includes lines of the form:
<stream number> <peripheral name> <output limit>
<code specification> <WHOLE if required> <title if required>
If the output is to be filed in the filing system, a line of the following form is used:
<stream number> TO FILE (<title/status>) <output limit>
If the file is newly created then the user must either be the owner or he must be a nominated part owner with allowed access status of F. If the file already exists then the user must have sufficient status to allow it to be updated. In which case the existing version is deleted automatically.
If C is the half-word addressed by ba and if C = J4, then input stream n is created from the data in the file whose title is in the 7 halfwords following C.
If C is the half-word addressed by ba and if C<0 and even, then output stream n is created. The half-word following C contains the estimated amount of output and the 7 half-words following that contain title/status for the file to which the output is to be sent.
If the current output stream is a pending stream then it can be assigned to a file by putting n equal to the address of the first of 9 halfwords. The first being negative and the third to the ninth containing title/status.
Create backing store device number Ba. If n is odd, the backing store device is associated with a file.
| If n = m.1 J4 | |
| create a new file. | |
| If n = m.1 | |
| use an existing file with writing permitted. | |
| If n = m.3 | |
| use an existing file in read only mode. | |
In each of these m is the store address of 8 half-words. The first specifies the estimated output limit and the remaining specify the title. If n = m.1 J4 then the title and status must be specified
Call file master special facility n. This extracode overwrites the contents of Ba in all cases even when no response is specified.
The following is a list of the special facilities available to the normal user.
| n = 1.0 | Delete file. | ||||||||||
| Delete the file whose title is in the 6 half-words addressed by ba. | |||||||||||
| n = 1.4 | Change status. | ||||||||||
| Change the status of the file specified to the value given. ba is the address of 7 half-words containing title/status. | |||||||||||
| n = 2.0 | Set key. | ||||||||||
| The key for the user of this extracode is reset. ba is the address of 2 half-words which must contain the existing value of the key followed by 2 half-words which contain the new value. | |||||||||||
| n = 2.4 | Unlock. | ||||||||||
| ba is the address of 4 half-words the first two of which contain the name of a file owner and the next two his key. If the key is correctly specified the user becomes a recognized key holder for the files of the named file owner. At any one time the user can be a recognized key holder for at most one other person's files. | |||||||||||
| n = 3.0 | ba' = attribute X of file Y | ||||||||||
| n = 3.4 | Set attribute X of file Y = V | ||||||||||
| The data held by the system about individual
files is only accessible by certain people. A list of the different
data items, their code numbers (X), and who is permitted to use them
will be published in due course.
ba is the address of the 6 half-words containing the file title which is followed by the attribute code number X and, if n = 3.4, X is followed by a half-word containing V. | |||||||||||
| n = 4.0 | ba' = attribute X of entry M for user A. | ||||||||||
| n = 4.4 | Attribute X of entry M for user A = V. | ||||||||||
If M = 0, then the attributes referred to are
those associated with the file owner A. Otherwise M is an integer (in
D3) specifying an entry in the file dictionary for A. If X = 0 and n
= 4.0, then
In other circumstances, the action is as for n = 3.0 and 3.4 but ba is the address of 2 half-words specifying A followed by one half-word containing M, one containing X and, if required, one containing V. | |||||||||||
| n = 5.0 | Create a part-owner of my files. | ||||||||||
| ba is the address of 2 half-words containing the name of a user who is to be given the status of part owner. If he already has this status then this extracode re-defines it. Following the title of the part-owner are 8 characters containing component B or zero. B is used to restrict the part owner to one set of files. Following this is one half-word containing the internal code for the usage status to be awarded to the new part-owner. | |||||||||||
| n = 5.4 | Remove part-owner. | ||||||||||
| ba is the address of 2 half-words containing the title of a part-owner who is to lose his part-owner status. | |||||||||||
| n = 6.0 | Erase disc copy of file. | ||||||||||
| ba is the address of 6 half-words containing a file title. This file is erased on disc and if not already dumped on magnetic tape is deleted. 1026/6.0 should be used if some part of a file is found to be unreadable or to have been destroyed. |
A provisional version of the file master will shortly be available for restricted use. The program does not include the archive mechanism and Class A files are handled as if they were Class T. Users should therefore make their own standby arrangements.
The errors which are detected by the file master give rise to Fault 20 with information about the type of fault in B91, This is as follows:
| 200.1 | File in use by another person and the requested action must be postponed. |
| 202.1 | File requested has been off-loaded and must be recovered before it can be used. |
| 204.1 | The file master facility requested was not available at the time when it was requested, e.g. file access was requested when the file master was engaged in a re-start operation. |
| 100 | Disc space allocation exhausted. File has been re-filed as Class T if possible. |
| 102 | User's directory is full. File cannot be filed. |
| 104 | User does not have adequate status to carry out the requested action on the file specified. |
| 106 | File name unknown. |
| 108 | File owner unknown. |
| 110 | Erroneous file title. |
| 112 | Illegal value of n in 1026 extracode. |
| 114 | Key or password incorrectly specified. |
| 116 | Attribute code number X out of range. |
Under some circumstances a user error will cause a file to be lost (e.g. after error 102). In this case 1.0 will be added to the error number.
If, for some reason, the file master is disabled when a user requires to use it, then he will be monitored with fault 20 and B91 = 0.
AGF
August 1966.
Copyright © 1966 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: 13. Input and Output in
Foreign Codes, MFB and BL, 17 November 1966
Next Planning Document: 15. Outline Scheme for
Log-in, Accounting and Control, DWB, August 1966
Return to Cambridge Supervisor Planning Documents
Return to CUCPS TITAN page
Return to CUCPS home page
Return to University of Cambridge home page