Users may store information in named files in the GEORGE filestore. GEORGE automatically allocates backing store space to filestore files, locates files when required and keeps copies on magnetic tape in case the files become corrupted. The user is not concerned with their physical locations on discs or magnetic tape, he simply refers to files by names which he gives them. Files are permanent; GEORGE will look after them until the user erases them. The filestore is a very convenient means of storing all the information jobs, source and compiled programs, data and even documentation - concerned with a project. The majority of users of GEORGE will use the filestore exclusively. However, filestore files are not always suitable for holding large amounts of data. There are two reasons:
It is therefore possible to use discs or magnetic tapes directly (see Part R) if an application makes this necessary.
There are many GEORGE commands which relate specifically to filestore. These are described by examples in later chapters here, but reference should be made to D.3 for formal definitions of the commands.
There are two categories of file: terminal files and directories'. Terminal files are set up and maintained by the user for his own requirements, such as text or binary storage. A directory is a file which GEORGE maintains as a record of a user's files. Every accredited user has one main directory (known as his proper directory) and this will contain a record of terminal files and possibly any other subsidiary directories (see C.2.1) which he creates.
Directories are referred to by their usernames; in particular, the username of a proper directory (known as the proper username) is the name by which the user identifies himself, and is generally known, to GEORGE. Proper usernames are allocated by ACL and consist of a colon followed by an identifier which (at ACL) is six characters An example is:
:NTBE34
It is always of this form: four letters and two digits. The first two letters represent a project identification code; the second two form a user location code.
The proper username must always be given in the LOGIN and JOB commands.
There are two common types of terminal file:
Basic files normally contain text: for example, source code. They have a format which allows GEORGE to use such files to simulate basic peripherals (card readers/punches, papertape readers/punches or lineprinters). The user may input data into basic files, directly from a primary input medium (punched cards or paper tape) or from a MOP terminal. There are powerful GEORGE facilities to manipulate such files.
Basic files consist of a sequence of records (generally each record represents a line of text; for example, a single punched card) which are accessed in order.
Direct Access files appear to the user to be a contiguous area of backing store space which can contain data organised in ways allowed for direct access peripherals. The most common use is for the storage of binary and semicompiled programs. The format is then of no concern to the user since TASK and other systems create such file as necessary. However, there are occasions when a user needs his data to be accessed randomly and he will then set up direct access files himself.
Files may be created, and other operations performed on them, by GEORGE commands. They are also, of course, read from and written to by programs. After loading a program, a file is assigned (D.4 states how this is done) to a particular program channel and from then on the program inputs from (or outputs to) the file just as if it were a peripheral device. Thus if the program channel CR0 (Card Reader channel zero) is assigned to a basic file, the program will subsequently behave as if it is reading cards from a card reader. From the point of view of user programs, files simulate peripheral devices; indeed many programs which were written in a pre-GEORGE environment run without change under GEORGE when filestore files are assigned to their program channels.
Assignments are performed using the ASSIGN command or through TASK or other systems (which themselves issue ASSIGN commands).
Note that under GEORGE it is seldom necessary for a user program to read from, or write to, a slow peripheral directly. For example, if a program produces output which needs to be printed, this is achieved by writing the output to a basic file which is then listed (using the GEORGE command LISTFILE). This system prevents the execution of user programs being slowed down by input or output on slow peripherals.
Once a user has been given a username, he may create files in his directory. The user is the owner of files in his directory. Although the filestore is designed to allow anyone to access any files to which he has authorisation, there are certain operations on a file which may only be performed by its owner. These are:
A user with a large project may set up directories inferior to his proper directory. These are known as pseudo user directories. The reason for doing this is to divide the files into convenient groups.
Instead of all being put in the proper directory, the files are shared out among several pseudo user directories. For efficiency reasons, a user should not create pseudo user directories unless he has a fairly large filestore, say at least 30 files.
Pseudo user directories have usernames (pseudo usernames) just as proper directories (that is identifiers preceded by a colon). The names are chosen by the user but are unique throughout the GEORGE filestore so if a user tries to create a pseudo user directory with a name duplicating an already extant one, an error message will be given and he will have to think of another name. It is probably best to incorporate the proper user identifier in the pseudo username, thus:
:NTBE34PS1
Certainly pseudo usernames must not clash with any potential ACL proper username. The identifiers must therefore be:
A pseudo user directory is set up using the MAKEDIR command. An example is:
MAKEDIR :NTBE34PS, :NTBE34PS,PSEUDO
The second parameter gives the pseudo username; the first is the local name (see C.2.2) which should be the same as the identifier of the username (this is for efficiency reasons). The third parameter is always PSEUDO.
Note that ownership of all files within pseudo user directories lies with the proper user.
Every file in the filestore has an identifier (the file identifier) and no two files entered in the same directory may have the same identifier unless distinguishing details are added. Thus if user :NTBE34 has a file called SOURCE in his proper directory, an attempt to create another file called simply SOURCE in this directory will fail or overwrite the existing one in certain circumstances. (However, he could create a file called SOURCE in a pseudo directory.) The extra details that may be added are given in brackets after the identifier and specify a generation number and a language code. The file identifier, together with these optional fields, is known as the local name. Note that directories have local names although these are normally of little interest to the user. GEORGE gives directories a local name with a generation number 1 and a language code C1.
A file can have any generation number between 1 and 4095. If the user wishes to specify a generation number when creating a file, he can give it either as an unsigned number or as a number preceded by a plus or minus sign. If a sign is prefixed, the number specified is taken as relative to the highest existing generation of a file with the same file identifier. The generation number parameter is put in brackets after the file identifier. For example, suppose the user has the following files entered in his proper directory:
SOURCEFILE(1) SOURCEFILE(3) SOURCEFILE(4)
He can create a further file in the series, with generation number 2, by issuing an appropriate command with either of the following filename parameters:
SOURCEFILE(2) SOURCEFILE(-2)
To create a file in the series with generation number 5, he must give one of the following parameters:
SOURCEFILE(5) SOURCEFILE(+1)
If the user omits the generation number in a filename when referring to an existing file, GEORGE will take the highest generation that it finds in the directory. Thus a reference to SOURCEFILE in the above example would denote SOURCEFILE(4).
If a user does not specify a generation number when creating a file, GEORGE provides a default value of 1.
Another way of differentiating between files with the same file identifier is by specifying language codes. A language code consists of up to 4 letters or digits beginning with a letter, or it can be left blank. If specified in_the local name, it is preceded by a solidus (/) after the generation number (if present). Examples are as follows:
SOURCEFILE(2/PROG) SOURCEFILE(/ALG) SOURCEFILE(2/F1)
If the user has two files with the same identifier and generation number but different language codes, and refers to the identifier without specifying the language code, GEORGE will take the first file it finds with this identifier and will not check the language code.
If a language code is not specified when a file is created, GEORGE provides a default of 4 spaces.
The local name of a file can be changed using the RENAME command (D.3.7, D.7.5). An example is:
RENAME SOURCEFILE(2),NEWSOURCE
The file SOURCEFILE(2) is renamed NEWSOURCE. The generation number and/or language code are unchanged unless new ones are specified:
RENAME SOURCE(3),NEWSOURCE(5) RENAME SOURCE(3),SOURCE(4)
A file with the new local name must not already exist.
Any file in the filestore is specified uniquely by quoting the directory it is in and the local name. This form of specification is known as the absolute name'. Examples are:
:NTBE34.SOURCE :GRAPHICS.DRAW(3)
A fullstop separates the directory from the local name.
A user normally refers to files in his own directory by giving simply the local name. Thus after logging in, the user :NTBE34 may refer to :NTBE34.SOURCE simply as SOURCE. The directory :NTBE34 is implied: it is the job's current directory. If the user wishes to refer to a file in another directory, he must either specify the absolute name or change the current directory. The latter is achieved by using the DIRECTORY command. An example is:
DIRECTORY :GRAPHICS
This command simply specifies that any relative filenames subsequently encountered should be regarded as being in :GRAPHICS. Thus a reference to the file DRAW would be taken as :GRAPHICS.DRAW. The file SOURCE in the example above would then have to be referred to by its absolute name :NTBE34.SOURCE unless another DIRECTORY command was issued to change the current directory back to :NTBE34.
This applies to file creation as well. If, after issuing the command DIRECTORY :GRAPHICS, a file is created and given the local name X, it will be recorded in :GRAPHICS.
The MAKEDIR command can be used to create a pseudo directory subsidiary to another pseudo directory.
An example is:
MAKEDIR NTBE34FILMS,:NTBE34FILMS,PSEUDO MAKEDIR GRAPHICS,:GRAPHICS,PSEUDO DIRECTORY :GRAPHICS MAKEDIR GRAPHICSDRAW,:GRAPHICSDRAW,PSEUDO
The user has 3 levels of directory:
This could be useful if one proper username is given to a project on which numerous people (each of whom would create their own pseudo directory) are working. Within the pseudo directories, there may be a need for further structure of filenames.
For efficiency reasons, not more than two levels of pseudo directory should be created.
The term filename is used for any valid specification of a file in a GEORGE command - relative or absolute, with or without generation number or language code specified.
When used in GEORGE commands, filenames often have qualifiers added to them. A qualifier gives GEORGE more information about the file or the mode of use of the file in the particular file operation being performed. Thus the qualifier WRITE applied to an output file implies that the file is to be written from the beginning; APPEND would mean that further information is to be added to the end of the file without disturbing the initial contents. The qualifiers applicable in various circumstances are described in the appropriate sections.
Qualifiers consist of one or more of a set of standard keywords (if more than one they are separated by commas) contained in brackets after the filename. Examples are as follows:
SOURCE (APPEND) :GRAPHICS.DRAW(2) (WRITE) :JDMSDIRECT.OBJECT(3) (APPEND,NOWAIT)
Note that qualifiers follow the bracketed generation number/language code if present. GEORGE can distinguish the set of qualifiers which will never begin with a number or solidus (/).
The user can discover which files he has in a directory by use of the LISTDIR command (D.3.11). (This also lists the names of any magnetic tapes the user owns: in some ways these are treated like files and entries about them are kept in directories: see Part R.)
The listing is sent to the MOP terminal or monitoring file (if issued from a background job) or can be sent to the lineprinter as a separate document. The listing level can be LOW when just the local name of each file is given, or HIGH when additional information (when last written, last accessed and so on) is given. Examples are as follows:
(1) LISTDIR :NTBE34,LOW (2) LISTDIR :GRAPHICS,HIGH,*LP (3) LISTDIR (4) LISTDIR ,,*LP
In (1) and (3) the listing will be made in the monitoring file of a background job or directly on the terminal of a MOP job. In (2) and (4), the *LP parameter specifies that the listing is sent to the lineprinter as a separate document.
If the username parameter is null (examples (3) and (4)), the current directory is assumed. The default LOW is assumed if the second parameter is absent.
A user can list all his directories at once, and also obtain a summary of his total filestore use, by using the utility LSTR (see Part T).
Note that in a HIGH directory listing, the size of a file is given in blocks. GEORGE internally manipulates files in blocks of 512 words. The size of files is of interest since the filestore accounting system (I.3.3) expresses the control on the size of each user's filestore in terms of total blocks allowed and number of files.
Basic files are of three types, GRAPHIC, NORMAL and ALLCHAR, according to the type of data they contain. In a GRAPHIC file the characters belong to the basic ICL 1900 Series 64-character set. Most text data is GRAPHIC and users are recommended to use this type of file wherever possible since it is more efficient to represent internally, to edit and to manipulate generally. NORMAL and ALLCHAR data {sometimes collectively called 3-shift data) are data in which the characters belong to the 1900 Series 3-shift set, which includes lower case letters and certain control characters. The only difference between the character sets for NORMAL data and ALLCHAR data is that the latter includes the whole 128-character set whereas the former excludes the two characters runout and delete (E.5, E.6).
Basic files consist of records (or lines) accessed serially. Each record may be from 0 to 2000 characters in length. In addition, GEORGE keeps a paper feed control character (PFCC) for each line, although this is only relevant if the file is listed on a lineprinter. It controls whether the paper is advanced one or more lines or a pagethrow is given.
Note that the size of a basic file is determined solely by the amount of data in it; it is automatically increased as more records are written in.
A basic file may be created by any of the following GEORGE commands:
(1) INPUT (2) ASSIGN (3) COPY (4) EDIT (5) SAVE (not described here, see D.4) (6) JOB (see C.9.2) (7) ENDJOB (with RETAIN parameter, see Part D)
If a file already exists with the filename of the one to be created, it will be overwritten (user traps permitting: see C.7). If a new file is being created it is normally GRAPHIC unless the new filename is qualified by qualifiers ALLCHAR or NORMAL (the exceptions are given in later sections).
Any of the commands INPUT, ASSIGN and COPY may be used to append records to the end of an existing basic file. To specify that he is appending records, the user qualifies the filename in the command with APPEND. If the named file does not exist, it will be created and written to from the beginning just as if APPEND had not been present.
Source text is initially put into a basic file using the INPUT command (D.3.2). If used in a background job or after logging in at a MOP terminal, the format is:
INPUT filename,terminator
The terminator (optional) consists of up to four characters preceded bv an S or T.
Examples are as follows:
(1) INPUT SOURCE (2) INPUT SOURCE(+1) (3) INPUT MYFILE,T???? (4) INPUT :GRAPHICS.DRAW(APPEND),S////
Example (1) creates the file SOURCE(1) if no file called SOURCE already exists. Example (2) will create a new file with a generation number 1 higher than the highest existing one. Example (4) specifies that input is appended to any existing contents of the file :GRAPHICS.DRAW.
The INPUT command is followed by lines of data which GEORGE will input until a line starting with the specified terminator is reached. The terminator will itself be included in the file if it was preceded by S in the command, and not if it was preceded by T. If no terminator was specified (as in the first two examples) the parameter S**** is assumed. Thus a user may type:
INPUT SOURCE THIS IS MY FILE ****
The final **** will be in the file; if the user did not wish this, he would have begun
INPUT SOURCEFILE,T****
When the INPUT command is used in a job like this, it is said to be embedded input. This is to distinguish it from use of the command outside a job. In this case data is input to a file without the user supplying a JOB card. The proper username must then be given:
INPUT :NTBE34,SOURCEFILE,T//// source data ////
This form of input is not permitted if the user is a high security user.
The user must be careful about terminators if using embedded input in a background job.
An example which would fail is as follows:
JOB MYJOB,:NTBE34,JD(JT 30 SECS) INPUT SOURCEFILE ...... **** further GEORGE commands ENDJOB ****
After the JOB card is read, GEORGE will place all the input up to the terminator into a temporary file (C.9.2) before beginning to obey commands.
The first **** will terminate the whole job, not simply the INPUT, and the further commands will not be obeyed. A different terminator must be used:
JOB MYJOB,:NTBE34,T////,JD(JT 30 SECS) INPUT SOURCEFILE ...... **** further GEORGE commands ENDJOB ////
If embedded input is contained in a background job like this, it is actually read twice, once when the whole job source is read into a temporary file, and once when the INPUT command is actually obeyed and the records are transferred into SOURCEFILE. It is thus more efficient to do the INPUT outside the job:
INPUT :NTBE34,SOURCEFILE ........ **** JOB MYJOB,:NTBE34,JD(JT 30 SECS) ........ ****
If a job is to be run more than once, it is common to INPUT the commands of the job into a file and then issue a RUNJOB on this file, rather than to continually resubmit the same deck of cards:
INPUT :NTBE34,JOBFILE GEORGE commands **** RUNJOB MYJOB,:NTBE34,JOBFILE,JD(JT 30 SECS)
This will be converted to GRAPHIC form unless either of the qualifiers NORMAL or ALLCHAR is present on the filename. If NORMAL is given, runout or delete characters on the paper tape are ignored. Each newline character on the paper tape will result in a new record in the filestore file. If there are 2000 successive characters without a newline, a new record will also be started. As both carriage return and linefeed produce new records, blank lines will be inserted.
The user can create a copy of any terminal file that he is allowed to read by means of the COPY command. Examples are as follows:
(1) COPY SOURCE1,SOURCE2 (2) COPY SOURCE,SOURCE(+1) (3) COPY :NTBE34.DRAW,:GRAPHICS.DRAW (4) COPY SOURCE(3),NEWSOURCE(2)(APPEND)
The first parameter gives the name of the file to be copied. This may belong to another user (example (3)). The second parameter gives the name of the copy. An existing file with this local name would be overwritten (assuming it has a write trap - see C.7). Example (2) would copy the highest generation of file SOURCE to a new file SOURCE with one higher generation number. The APPEND qualifier can be used on the second parameter; example (4) indicates that a copy of the basic file SOURCE(3) will be appended on to the end of the basic file NEWSOURCE(2) without disturbing the original contents.
If a new file is being created, it must (by the rules of ownership stated in C.2.1) be in the user's proper directory or one of his pseudo directories. It is possible, however, to use the COPY command to overwrite a file already existing in another user's directory, assuming the owner has given authorisation.
The GEORGE command language gives very powerful facilities for editing basic files. These are used through the GEORGE EDITOR which is called by the EDIT command. Editing in GEORGE is like copying inasmuch as a new file is created and the old one is undisturbed during the editing process. The new file must then be given a different local name from the old one. It is usual simply to change the generation number, increasing it by 1 each time the file is edited. The CORRECT macro achieves this and erases the old file afterwards to avoid proliferation of unwanted versions of files. Use of the GEORGE EDITOR is fully described in Part G.
When a user program needs to read from, or write to, a basic file, the file must first be assigned (connected) to an appropriate channel of the program. The program will then make input/output transfers just as if it were using real devices like lineprinters or card readers. Program input/output is fully described in Part R.
Connection of GEORGE filestore files to program channels is done by means of the ASSIGN command (D.4.7). The user of the TASK system will rarely use this explicitly since TASK issues ASSIGN commands on his behalf. Examples of the ASSIGN command are as follows:
(1) ASSIGN *CR3,:GRAPHICS.DRAW (2) ASSIGN *LP2,LISTING(3) (3) ASSIGN *LP1,LIST(APPEND) (4) ASSIGN *CP2 (5) ASSIGN *CR1 (6) ASSIGN *TR1,TAPE (NORMAL)
Example (1) specifies that the file :GRAPHICS.DRAW is connected to card reader channel 3. Input files are always read from the beginning. In example (2), LISTING(3) is connected to lineprinter channel 2. If the file LISTING(3) already exists, it will be emptied (that is effectively erased and a new one created) when the assignment is performed. If not, it will be created. Output files can be opened in APPEND mode (example (3)) when any output will be appended to the existing contents.
If no filename is specified in an output basic file assignment (example (4)), output from this channel will be listed directly into the monitoring file. If no filename is specified in an input basic file assignment, transfers to this channel will be read directly from the job source (that is, the job description file in a background job or the MOP terminal if the user is doing interactive programming with a fully-started MOP job).
Output to a paper tape file (channel of type *TP) may be specified as GRAPHIC, NORMAL or ALLCHAR by a qualifier (the default is GRAPHIC). During reading, GEORGE makes any necessary conversions, for example, if a NORMAL file is assigned to a *CR channel.
Files can be opened for many users simultaneously, but normally if a file is open for writing (or appending), no other user will be able to open it. An attempt to open it for reading while another job is writing to it, or vice versa, will result in the message WAITING FOR FILE TO BECOME FREE being sent to the monitoring file, and the job will suspend until the file becomes free.
This type of suspension can be avoided by using the REPLY qualifier on the ASSIGN command; the above circumstances will then lead to an error being given by the command and the continuation of the job.
A program which goes out of control may continue to write to a basic output file until the file is full (245K words). This can be very costly, particularly if the job subsequently lists this file on a lineprinter. There is thus a user-controlled limit on the number of output transfers allowed on a basic file. If exceeded, the program halts and an error message is given. The default value of the limit is given by the value of the installation parameter VOLUME. This is currently set to 8000 transfers and should be large enough for most purposes. To override the default, a LIMIT qualifier must be put on the filename in the ASSIGN command.
ASSIGN *LP2,OUTPUT(LIMIT14000)
The above statement will allow 14000 transfers to the file OUTPUT.
If the file being assigned is not in on-line storage (see C.8.1), the command is normally suspended while the file is automatically retrieved from magnetic tape. In some circumstances a user may wish not to make the assignment if the file is not on-line and the NOWAIT qualifier allows him to do this. If NOWAIT is present and the file is off-line, the command will generate an error, and the next command will be processed. Full details of what is meant by on-line and off-line are given in C.8.1.
The LISTFILE command (D.3.3) is used to list basic files on the lineprinter, monitoring file (or the MOP terminal), punched cards or paper tape.
The parameters of LISTFILE normally specify the name of the file, the type of peripheral on which it is to be listed, which lines are to be listed (if only part of the file is required) and whether the listing is to be numbered. Parameters more rarely used are the ALL and property parameters (see below).
Note that the LISTFILE command for the lineprinter and card or paper tape punch results in an entry for the file concerned being put on a GEORGE queue for the appropriate device. The next command in the job is obeyed without waiting for the listing to be completed; this may be a long time later if the file is currently in use, the required listing devices are not working or there is a large queue of output (quite common for the lineprinter). While there is such a LISTFILE outstanding for a file, the file cannot be opened for writing (it is just as if another user had it open for reading). For efficiency reasons, therefore, after a LISTFILE has been issued, the same file should not be re-used to output further results, otherwise the ASSIGN command will be held up waiting for the preceding LISTFILE to complete.
If no peripheral type is specified in the LISTFILE command, the file will be listed into the monitoring file or, if a MOP job, directly on to the terminal. The monitoring file itself is normally listed on the lineprinter at the end of a job (unless specified otherwise by the user: see ENDJOB command in D.2); GEORGE effectively issues a LISTFILE for it.
Examples are:
(1) LISTFILE SOURCE,*LP (2) LISTFILE FORTRANSOC,*LP,FROM52,LINES25,NUMBER
The document produced begins with lines of asterisks and headings giving the username, jobname, filename, date and time LISTFILE issued and the date and time the listing was actually produced. The precise format of this is always liable to change. At present, the listing of the file follows the headings without an intervening page-throw, so programs should supply one if output is required to begin on a separate page.
If a record is too long to be output on a line (116 characters on ACL printers), a hyphen is inserted at the end of the line and the record continued, indented 4 characters, on the following line. No automatic paging will occur so page-throws should be included, if required, when the file is written (there are 51 lines per page on ACL printers).
If the file was created by INPUT and normal editing, the PFCC (C.3.1) will indicate single-line feed so no page-throws will be present. The H facility of the EDITOR (Part G) can be used to insert page-throws or double spacing as required.
Example (2) gives a selective listing of 25 lines from line 52 (the first line is treated as numbered zero). The NUMBER parameter causes the lines to be numbered sequentially on the listing. The numbers give the position of the line in the file and occupy the first 7 characters of the printed line followed by a space. A numbered listing is very useful if the GEORGE EDITOR is to be used subsequently to change certain lines.
Examples are:
(1) LISTFILE CARDFILE,*CP (2) LISTFILE MYSOURCE,*CP,FROM100,NUMBER
Only the first 80 characters of each record will appear. If NUMBER is present, the cards will be numbered in increments of 10, the number appearing in columns 76 to 80 of the card (replacing anything that previously appeared in these columns). The first card is numbered 10 or 10 × n if FROM n is specified. Note that no LINES parameter is given in example (2) so the whole file from line 100 will be listed.
Each record is terminated by a newline character and three runout characters unless the file is of type ALLCHAR in which case only newline is supplied. The punched file will be preceded by a heading in visible characters and some blank tape.
The NUMBER parameter is not allowed. The ALT parameter is described below (C.3.6.7); its use is recommended for LISTFILEs to paper tape.
An example is:
LISTFILE MYSOURCE,FROM50,LINES10
The file is listed directly into the monitoring file, the main disadvantage of this is that page-throws do not appear and the output is sandwiched between the GEORGE commands for the job. The main advantage is that there are less separate pieces of paper about the job to be collated by the operators (the various documents LISTFILEd by a job do not necessarily follow each other on the lineprinter but are interspersed with output from other jobs).
Note the warning in (C.3.6.8) about trying to list open files to the monitoring file.
In a MOP job, the LISTFILE command is used as above to obtain a listing of a file on the MOP terminal.
This can be used to direct a listing to a device at a particular site. Normally, files will be listed on a device local to the issuing job. Thus if a job submitted at ACL or from a MOP terminal issues a LISTFILE with a *LP parameter, the listing will appear on one of ACL's printers while a job submitted at a remote job entry (RJE) station will list its output on printers or other devices attached to this station. These rules can be overridden by specifying a PROPERTY parameter (F.2.1) on the LISTFILE command:
(1) LISTFILE MYFILE,*LP,PROPERTY CENTRAL (2) LISTFILE MYFILE,*LP,PROPERTY BELFAST
Example (1) will list the file on an ACL printer even if the job is submitted on the Belfast RJE station, while example (2) will list it on the Belfast printer even if the job is submitted at ACL.
This specifies that if there is some interruption during the output of a file (for example, the lineprinter jams), the whole file will be output again. Otherwise, the output may be in two parts with repeated lines or pages. It is recommended that ALL is always used with paper tape output. It is not necessary with the lineprinter unless a listing broken into two parts is quite unacceptable.
Since a LISTFILE to a peripheral device simply causes an entry to be put on a GEORGE queue with the actual listing being performed later, it is possible to issue a LISTFILE for a file which is open for writing at the time. Thus a common sequence is:
ASSIGN *LP1,RESULTS LISTFILE RESULTS,*LP
The LISTFILE command will be accepted by GEORGE even though the file is opened for writing (being assigned to a lineprinter program channel). It will not be implemented (that is, the listing will not appear) until the file is closed, when the whole file is listed. This is more efficient than waiting until the program ends and then issuing the LISTFILE since listing may begin as soon as the file is released (which may be before the program has ended).
This cannot be done for a LISTFILE to the monitoring file:
ASSIGN *LP1,RESULTS LISTFILE RESULTS
This would fail because a listing to the monitoring file must be done straight away; it is not an autonomous activity. Since the file is open for writing, listing it (which implies reading it, of course) is not allowed. The LISTFILE must only be issued when the file is released from the channel.
Direct access filestore files are heavily used in the GEORGE system since both semicompiled and binary programs are usually stored in direct access form. However, in these particular cases, the user is not normally concerned with the formats of the files; the TASK system creates and manipulates such files and the user will just provide local names as necessary and perhaps erase the files when he has finished with them.
The user will only create and manipulate direct access files himself if his application requires random access to binary data. Unlike basic files, direct access files can only be read or written by programs (there are no equivalents of the INPUT or LISTFILE commands). The user should be warned against using direct access filestore files for large scale data processing. Direct access packages and utilities which were written to access disc hardware will usually be concerned with efficiency and try to optimise disc head movement. Using these with GEORGE filestore files can be very inefficient. Large scale users should consider using exofiles (R.2.6).
Direct access files have a format derived from that of a real disc (see Part R). Each file can be regarded as being in fixed length pieces known as buckets. The bucket size, specified when the file is created, is either 128, 256, 512 or 1024 words long (semicompiled and binary program files must have a bucket size of 128 words). An input or output operation in a program normally reads or writes a specified bucket (buckets are numbered from 1 upwards). Unlike basic files, direct access files are created with a certain size before they are written to (although a user program can extend them later on). It is thus possible to create a direct access file and then start reading buckets, although the initial contents are undefined.
Direct access files may be created by any of the following GEORGE commands:
(1) COPY (2) CREATE (3) SAVE (see D.4)
This is used in the same way as for basic files.
Examples are:
COPY :NTBE34.DISCFILE,MYDISCFILE COPY :GRAPHICS.DRAW-SEM,SEMI
A new file will be created, or an old one overwritten, with exactly the same structure and contents as the copied file. If an existing file is overwritten however, it must be a direct access file. Note there is no equivalent of APPEND mode for direct access files.
A direct access file is normally created by the CREATE command (D.7.7). The information GEORGE requires is given as a qualifier list after the new filename. There must not be a file of the same name already. Qualifiers are as follows:
*DA must be present
KWORDS n (where n is a decimal number) gives the size of a file
in units of 1024 words
BUCKETS n (where n = 1, 2, 4 or 8) gives the bucket size (128 × n words).
Default is BUCKETS4
For example:
CREATE DISCFILE(*DA,KWORDS 10,BUCKETS 8) CREATE DISCFILE(2)(*DA,KWORDS 1)
The first example creates a 10K file with 1K buckets. The second creates a file (generation number 2) with two 512-word buckets.
Users should guard against creating larger DA files than they actually need. Space is allocated as backing store whether or not it is actually used.
Connection to program channels is achieved by the ASSIGN command (D.4.7). If the file is to be written to, the qualifiers WRITE or OVERLAY (which have the same effect in filestore files) must be present. Direct access channels have the form *DAn. Eor example:
ASSIGN *DA1,DISCFILE ASSIGN *DA2,RANDOM(OVERLAY)
If an existing direct access file is to be opened for writing, and its current contents are of no interest, the EMPTY qualifier should be given. This will avoid retrieving the old file from magnetic tape (C.8.1) in certain circumstances. EMPTY implies WRITE.
The initial contents of a newly-created direct access file, or a file opened with the EMPTY qualifier, are undefined:
ASSIGN *DA1,NEWDATA(EMPTY)
A file is deleted by using the ERASE command (D.3.8). For example:
ERASE MYFILE(-1) ERASE :GRAPHICS ERASE SOURCE1,SOURCE2,SOURCE3 ERASE :VTMB23.HISFILE
Traps are normally set to allow erasure of files (C.7). Important files should be protected by removing the ERASE trap. If a directory is erased, every file within it will be automatically erased (C.7.2).
An ERASE command can be issued for a file that cannot yet be physically erased because it is connected to a program in this or another job or has an outstanding LISTFILE open (C.3.6). The file will then be marked for erasure although this will not physically occur until later. An example is as follows:
ASSIGN *LP2,LISTING LISTFILE LISTING,*LP ERASE LISTING
The file LISTING will not actually be erased until the program has released it and it has been listed, although any attempt to access this file with a later command will give an error message. An attempt to create a new file called LISTING will give the message:
WAITING FOR FILE TO BE ERASED
The command will then suspend itself.
Workfiles are temporary storage files that are associated with a job only for the duration of that job. They are automatically erased when the job ends and any outstanding LISTFILEs have been completed. They are entirely local to the job which creates them and cannot be accessed by other jobs. They are simple to use and are very heavily used, particularly for output listings, where there is no more interest in the file once it has been listed.
Workfiles are kept in a workfile stack and are referred to by special workfile names. These consist of the character ! followed by a decimal integer which indicates the distance of the workfile from the top of the stack. The one at the top is the latest to be created, referred to as !0 or more simply !. The second latest is !1 and so on.
It is also possible to refer to a workfile relative to the bottom of the stack. !-1 refers to the oldest workfile, !-2 to the second oldest, and so on.
Workfiles are created by the CREATE command. To create a workfile which is a basic peripheral file (basic workfile), containing output to be listed, say, the command is simply:
CREATE !
Another example is:
CREATE ! ASSIGN *LP0, ! (LIMIT 2000) CREATE ! ASSIGN *LP1, ! (LIMIT 1000) LISTFILE !1,*LP
The final LISTFILE refers to the first workfile (assigned to *LP0).
If a job wished to access the oldest workfile in the job, and it did not know how many workfiles had been created since, it would refer to !-1. For example:
COPY !-1,MYFILE
It is possible to create direct access workfiles. The format is similar to the creating of ordinary DA files:
CREATE ! (*DA,KWORDS 5,BUCKETS 1)
Such a command might be issued by the TASK system when it creates a workfile for semicompiled output.
Use is exactly as for ordinary files:
ASSIGN *DA1, ! ASSIGN *DA3, !2
Any workfile can be erased and the stack is adjusted accordingly:
ERASE ! ERASE !2 ERASE !-2
Every file has user traps associated with it. These specify which users are allowed to access the file, and which mode of access they are entitled to use. These traps can apply to the owner of the file himself; a user may set traps to prevent himself, say, writing to or erasing one of his own files by mistake.
There are five modes of access to which user traps relate. These are:
READ WRITE APPEND EXECUTE ERASE
A user needs READ access to a file in order to ASSIGN it for input, to COPY or EDIT it or to LISTFILE it. He needs WRITE or APPEND access in order to WRITE or APPEND to it. EXECUTE access must be held to:
ERASE access must be held in order to delete a file.
If a user is allowed, say, READ access to a file, the file is said to have a READ trap set for this user. A command which attempts to access a file in a mode for which the user does not have a valid trap will give rise to a command error. The message is:
ERROR IN command: TRAPS CLOSED
The check is made when the first file is opened initially but at no other time. Thus, once a user has assigned a file for writing, he is not affected if the WRITE trap is removed when he is actually writing to it.
The user trap system also applies to magnetic tapes (see D.7).
Users are warned that macros and systems (for example, CORRECT, TASK) may alter the traps set for a file.
When a terminal file is initially created, a user trap is set granting the owner of the file ALL (that is, READ, WRITE, APPEND, EXECUTE and ERASE) access to it. No other user will have any access at all.
When a pseudo directory is created (by the MAKEDIR command), a user trap is set granting the owner READ access to the directory. The only other trap relevant for a directory is ERASE and this has to be set (C.7.3) before the user can erase it. This is to prevent accidental erasure which could be a disaster.
Having set an ERASE trap on a pseudo directory, the directory may be erased. This will erase all the files within it, even if some of these files do not have an ERASE trap set.
User traps are changed by the TRAPSTOP and TRAPGO commands (D.3); they can only be changed by the owner of the file. TRAPGO is used to set additional traps, TRAPSTOP cancels traps which already exist. Some examples are as follows:
TRAPSTOP SOURCE,ERASE TRAPSTOP MYFILE(2/A1).ERASE,WRITE,APPEND TRAPGO SOURCE.ERASE TRAPGO MYFILE(2/A1),WRITE,APPEND TRAPGO RESULTS,ALL TRAPGO :GRAPHICS,ERASE
ERASE and WRITE traps should always be removed from a valuable file to prevent accidental erasure by the owner.
The above examples apply to the owner of the file. To give (or remove) access to another user, the username is given as an additional parameter:
TRAPGO JOB1,:NTBE34,READ,EXECUTE TRAPSTOP PROG,:NTBE34,ALL TRAPGO MYFILE,:NTBE34,WRITE,APPEND
Access can be given to (or removed from) all users by the :MANAGER,GROUP parameters:
TRAPGO USEFUL,:MANAGER,GROUP,READ,EXECUTE TRAPSTOP MYFILE,:MANAGER,GROUP,ALL
A user can use the TRAPCHECK command (D.3.17) for two purposes:
Examples are:
(1) TRAPCHECK MYFILE (2) TRAPCHECK MYFILE,: NTBE34 (3) TRAPCHECK MYFILE,:MANAGER,GROUP (4) TRAPCHECK :NTBE35.HISFILE
The first example checks which modes of access the user has to MYFILE, the second checks which modes another user is allowed. Example (3) will discover if any traps are set for :MANAGER,GROUP (that is, everybody). Example (4) checks the user's access to some other file.
Examples of replies to the TRAPCHECK command are as follows:
PERMITTED ACCESS MODES IN MYFILE (1/ALG) BY :NTBE34 : READ,APPEND PERMITTED ACCESS MODES IN :NTBE35.HISFILE BY :NTBE34 : ALL YOU ARE NOT ALLOWED ANY ACCESS TO THIS ENTRANT
All the modes of access which may be granted or forbidden to a user by means of a TRAPGO or TRAPSTOP command mav also be granted or forbidden by the TRAPGO or TRAPSTOP qualifiers (D.1.3) in certain commands. These qualifiers have the format:
TRAPGO (list of parameters to TPAPGO command) or TRAPSTOP (list of parameters to TRAPSTOP command)
Examples are:
TRAP GO(:NTBE34,READ,EXECUTE) TRAPSTOP(:MANAGER,GROUP,READ)
They may be used to qualify the filename in any command which creates a new file or overwrites an existing basic file. Thus they allow creation and the setting of traps on a file in one GEORGE command. The relevant commands are ASSIGN, COPY, CREATE, INPUT and SAVE (they may also be used in the magnetic tape commands GET, GETONLINE and NEW).
Examples are:
ASSIGN *LP2,FRED(TRAPGO(:NTBE34, READ)) INPUT MYFILE (TRAPSTOP(WRITE, ERASE),TRAPGO (:NTBE34,READ)) COPY FILEA,FILE(TRAPGO(:MANAGER,GROUP,READ,EXECUTE))
Files can be accessed most efficiently if they are held on direct access storage. However, direct access storage is expensive and many files will be used infrequently. It is therefore economic for the system to hold files on magnetic tape and copy them on to a direct access device when they are required. Magnetic tape storage has another role which is just as important; it provides a copy of the filestore, albeit not completely up-to-date, from which the on-line filestore can be recreated in the event of serious corruption.
The user is not generally concerned with the location of any file; GEORGE handles all filestore management. If a command is issued to access a file which is not on-line (that is not on direct access storage), GEORGE will automatically retrieve the file from magnetic tape. However, this involves the loading of the tape by the operators, and the whole process may take several minutes. During this time the job will be suspended. To avoid such delays, the user should issue RETRIEVE commands for files he knows he will use later on. Examples are:
RETRIEVE MYFILE RETRIEVE :NTBE34.FILEA,:GRAPHICS.FILEB,FILEC
The job can then continue other activities while the file is being retrieved (if the file is already on-line, a message to this effect is sent to the monitoring file). By the time the file is needed, it will perhaps be on-line and there will be no delay. It is a good practice to include RETRIEVE commands at the beginning of a job for all files that are used in the job.
However files should not be retrieved if they are not going to be used (or if they are basic files which are to be overwritten) as this is wasteful of on-line space.
If a user does not issue explicit RETRIEVE commands, GEORGE will RETRIEVE the file if it is off-line when a command tries to access it. It is quite common for a user at a MOP terminal to issue, say, a LISTFILE to list a file on his terminal, only to find the file is off-line. A message is sent to the terminal:
filename IS BEING RETRIEVED
The command is then suspended. The user can simply wait but this is obviously wasteful of terminal time, since he could be doing something else while the file is coming on-line.
In such circumstances, he should break-in (E.2.1), and perhaps QUIT. This will not cancel the implicit retrieval and other work can be continued. When the file arrives on-line, GEORGE sends a message to the terminal:
filename IS NOW ONLINE
The LISTFILE can then be re-issued.
When a file is off-lined (that is, removed from on-line storage) depends both on its size and when it was last accessed. Small files used regularly will probably remain on-line all the time. Large files, which obviously cost more in on-line storage, tend to be off-lined fairly quickly. Any file not accessed for more than a week or so will probably be off-lined.
If it is known that a file will not be used for some time, GEORGE can be informed of this by the ARCHIVE command (D.3.14):
ARCHIVE SOURCEFILE
This enables GEORGE to off-line it as soon as on-line space is required. Files which will be unlikely to be required for a year or more should be removed from the filestore altogether (see COPYOUT, T.3.1).
Files are kept on magnetic tape not simply because of limited direct access storage but for back-up purposes in case part of a disc or drum becomes corrupted. The part of GEORGE which copies files to magnetic tape is known as DUMPER. This is not a continuous process; DUMPER is normally run once every 24 hours (usually at some time during the night) when all the directories and all files which have changed since the last dump are written to tape. (More than one copy is kept.) This set of information is called an increment. While DUMPER is running, any attempt to access a directory will cause the job to suspend. Users at MOP terminals will be informed of this by the message:
WAITING FOR DUMPER TO FINISH INCREMENT
It may take as long as an hour.
In many cases, corruption of the disc copy of a file will be detected by GEORGE which will fetch the dumped copy, if one exists. In the rare cases where GEORGE fails to recognise that a file has been lost, ACL staff will manually restore the file from its dumped copy. This is a troublesome procedure and ACL will generally not consider restoring a file to a user who has simply erased it by accident. Valuable files should thus have their ERASE traps removed (C.7.3).
The filestore is very secure, but it cannot be guaranteed that a file will never be lost in any circumstance. If a file contains information which it is considered could not possibly be reproduced, it would be wise for the user to take his own copy on a private magnetic tape (using COPYOUT: see T.3.1).
Occasionally an important file such as a directory will become corrupted on direct access filestore. At present, all GEORGE can do in such circumstances is call for a General Restore. This means restoring the complete on-line backing store from magnetic tape; the effect is that the filestore reverts to its state as at the last dump. Since dumps are taken every 24 hours, it is obviously possible, in the worst case, for a user to lose the results of a complete day's changes.
General restores have occurred at the rate of two or three a year (but are becoming rarer), so a user should not ignore the possibility.
System breaks, either hardware or software, normally have no effect on any files except those which are open for writing (including appending) at the time of the break. In general, files which are open for writing at this time are lost (but GEORGE will restore the latest dumped copy if there is one). This is usually not important, most files open for writing are being written by programs which would have to be re-run in any case. It can, however, be irritating if files at a MOP terminal are being created by INPUT or EDIT or CORRECT and a lot of work has to be repeated. It is advisable, therefore, if an extensive edit is being performed, to break it into parts, creating a new file after each part. Should a break occur, one phase of the work, at most, has to be repeated.
There are possibly two temporary files concerned with a job created by GEORGE. Entries for them appear in the user's proper directory and will occasionally be seen in directory listings, where they can be recognised by the (T) indicator.
Every job has its monitoring file in which details of the job's progress are recorded. It is created by the JOB, RUNJOB or LOGIN command. The local name is JOBNAME(1/B1B0) where JOBNAME is the jobname parameter.
This is created by the JOB command. The local name is JOBNAME (1/B5B1). The records following JOB up to the terminator are read into this file exactly like the INPUT command. GEOPGE then issues a RUNJOB command internally on this file.
There are various proper user directories in the system which do not correspond to genuine users but simply contain files for general use, These files will normally be trapped READ and EXECUTE for every user. Some of these directories are briefly described below.
The files in :LIB and :SUBLIB contain all standard programs (compilers, utilities and so on) currently available at ACL. :LIB contains ICL software, :SUBLIB contains software originating at ACL or elsewhere. Normally, the user will not need to make explicit reference to these files as most of them are accessed through standard macros.
This contains files of useful information, for example, descriptions of new versions of software.
This directory contains the system macros, that is macro definition files which may be called by all users as if they were GEORGE commands. When it processes a command, GEORGE searches its list of built-in commands, then the current directory and then :MACROS (if the command is still not found, higher levels of directory are then searched; thus in the example of C.2.3.2, if the current directory is :GRAPHICSDRAW, :GRAPHICS and then :NTBE34 are searched after :MACROS) . Thus when a user calls TASK, he is in fact obeying commands in the file :MACROS.TASK.
Most of the files under :OPERATORS are used by the Operations Branch staff. The only one currently of interest to users is :OPERATORS.JOBQ (see Part I).
This is the user who effectively owns all other users in the system. It is necessary to quote :MANAGER in one use of the TRAPSTOP and TRAPGO commands (C.7.3).