|
A user communicates with George 3, by means of commands expressed in a Job Command Language (JCL). A command consists of a key-word (or verb) followed by at least one space and a series of parameters separated by commas, e.g. LISTFILE DATAFILE,*LP This LISTFILE command would list the basic peripheral file DATAFILE on the line printer. The order of parameters is usually important; in the case of LISTFILE the filename must be the first parameter. Many parameters are optional; some have to be expressly quoted "null" when it is necessary to preserve the position of a parameter but a preceding parameter is not required. Commands are limited to one per line but if a command is too long for a single line it may be spread over several lines by ending all lines except the last with a hyphen. Commands can be optionally labelled by preceding the verb with a label (a sequence commencing with a number, e.g. 1ZYXW) followed by a single space, for example: 1LIST LISTFILE DATAFILE,*LP George 3 commands may be either built in commands or macro commands. Built in Commands For brevity and convenience all commands built into George have a two letter abbreviated form, e.g. LF DATAFILE,*LP is equivalent to the LISTFILE command. The most useful built in commands to run a job are briefly detailed in the following paragraphs. Fuller details are given in the section George 3 Commands. Macro Commands Most of the George built in commands are very basic and a great many such commands may be required for an apparently simple job. For example, to compile and run an Algol program supplied on cards could require at least 20 to 30 commands and this would provide no protection against errors. A more suitable set of instructions might require more than 100 commands. To avoid a user having to prepare and repeat long and tedious sequences of JCL, George allows commands to be stored in a file. The filename may then be written as a verb and all the commands stored within the named file will be obeyed. A command file used in this way is called a macro command. Macro commands may be written by users for their own use or may be provided by the Systems Team for general use. When George encounters a verb which is not a built in command it first searches the user's directory for a file with the name of the command. If this search is unsuccessful George then searches a special directory (:MACROS) to try and find the file. Macros provided by the Systems Team are all stored in the directory :MACROS and users must clearly ensure that they do not have files in their directory with the same name as these macros if they wish to use them. It is possible to supply parameters to a macro command, parameters which can be accessed from within the macro. Any description of how to write macros is beyond the scope of this Section and ICL manual TP4267 should be consulted by such interested users. A macro may within itself call other macros. Jobs A job consists of an ordered set of commands. The first command in the set introduces the job and associates with it a jobname and a username. A job may be run either off-line (Batch) or on-line (MOP). When any job starts to run, a temporary file, called the monitor file, is created for the job; messages concerning the progress of the job are sent to this file. At the conclusion of the job this file will normally be listed on the lineprinter and then erased; alternatively the monitor file may be retained by the RETAIN option of the ENDJOB or LOGOUT commands. By its nature the monitor file is a most useful, often essential, piece of information when tracing the actions actually performed by a job and/or identifying many causes of failure. An off-line job is initiated by either a JOB or a RUNJOB command, depending on whether a stored job description is to be used and may be submitted via either cards or paper tape or from an on-line terminal (RUNJOB only). Once the user has submitted such a job to the computer he has no further control over it. For an on-line job commands are typed at a console and each command is obeyed and a suitable response obtained before the next command is input. The user therefore has much greater control over an on-line job since he can interact directly with the system. File editing in particular is much less error prone when performed on-line. On the other hand, production running is often better handled off-line. Off-line jobs should be organised so that they can be
re-run without:
An on-line job is initiated by a LOGIN command from an on-line terminal. No job description file is required since commands are read from the on-line console as required. Any messages sent to the monitor file are also sent to the console so it is usually unnecessary to print out the monitor file. Context When a job is initiated by a JOB, RUNJOB or LOGIN command a user name is associated with the job. In George 3 terminology we say that the context has changed from NO USER to USER. When an ENDJOB or LOGOUT command is later obeyed the context reverts from USER to NO USER. There are several other contexts within the George 3 system. The most important of these occurs when a program is loaded, when the context changes from NOT CORE IMAGE to CORE IMAGE. When a core image is later deleted the context reverts to NOT CORE IMAGE. If the "break-in" facility is used on-line the context changes from NOT BREAK IN to BREAK IN. Commands typed in by the operator on the control console are said to be in OPERATOR context. Certain George commands may only be used in certain contexts and are forbidden in others. Some George 3 commands have different formats depending on the context. Creating a file (INPUT, COPY and RENAME) The INPUT command creates a basic peripheral file with the name specified provided the file does not exist. If the file exists then it will be overwritten providing the user has WRITE access to the file. All records following the INPUT command up to and including a record commencing with four asterisks **** are copied into the file. An alternative terminator to the INPUT command may be specified by an optional terminator parameter. When a file is being created from cards or paper tape then it is recommended that the INPUT command should be used in NO USER context (i.e. the INPUT command is not preceded by a JOB command. This is because when an INPUT is done in USER context (following a JOB command) it is necessary to copy all the file first into the temporary job description file and then into the file specified. This is inefficient and should be avoided. INPUT in USER context is mainly used from an on-line console after a LOGIN command has been obeyed. Since the LOGIN command does not create a job description file the inefficiency described earlier does not arise. When a file is created by an INPUT command all traps are left open (i.e. the user has READ, WRITE, APPEND, ERASE and EXECUTE access available to him). A TRAPSTOP (TS) qualifier may be used in parentheses after the filename to remove any of these modes. If a file is overwritten by the INPUT command the trap settings are left as they were for the original file unless a TRAPSTOP (TS) or TRAPGO (TG) qualifier is used to change the settings. The TRAPGO qualifier has the same format as the TRAPSTOP qualifier but gives rather than removes a mode of access. Both qualifiers may be given together. The mode of a file created by INPUT is assumed to be GRAPHIC (i.e. restricted to the 64 character ICL card code). If input is from paper tape and it is required to use the 128 character code then a NORMAL qualifier must follow the file name. Use of a NORMAL qualifier does not allow the use of runout and delete characters, so that in very rare cases it may be necessary to use an ALLCHAR qualifier rather than NORMAL. The INPUT command can also be used to append records to an existing file providing the user has APPEND access to the file and an APPEND qualifier follows the filename. It is not possible to APPEND records of one type e.g. NORMAL to a file of another type e.g. GRAPHIC. If the file specified does not exist then the APPEND qualifier is ignored and the file created in the usual way. The COPY command makes a copy of a file. If the new file does not exist it will be created and will be the same type as the old file. If new file exists it will be overwritten providing WRITE access is allowed. TRAPGO, TRAPSTOP and APPEND qualifiers may be used with the new file as for the INPUT command. COPY is often used to make a copy of a file belonging to one user under another user. The RENAME command strictly speaking does not create a new file but changes the name of an existing file. The ERASE command specifies files that are to be removed from the filestore providing the user has ERASE access. Up to 24 files may be deleted by a single ERASE command. Access to files (TRAPGO, TRAPSTOP and TRAPLIST) Access to files is controlled by traps. The following modes of access are allowed READ, WRITE, APPEND, EXECUTE and ERASE. A file is initially created with all traps open to the owner of the file. The owner (only) can change these traps and grant other users access by means of TRAPGO and TRAPSTOP qualifiers to the filename when the file is written or by the use of separate TRAPGO and TRAPSTOP commands. The access mode ALL may be used to indicate all the above access modes. The TRAPGO command grants access in the modes specified to filename. The username parameter may be omitted in which case the owner of the file is assumed. The TRAPSTOP command is analogous to TRAPGO but removes access. The TRAPLIST command enables a user to check the access modes allowed both to himself and other users. Output from the command consists of a single line for each user permitted access to the file. Other useful commands The LISTFILE command (mentioned above) enables a listing of a basic peripheral file to be obtained, to either a line printer, card punch, paper tape punch or to the monitor file (and therefore to the console for an on-line job). The LISTDIR command causes a summary of the files owned by the user specified to be output. The ABANDON command allows a job that a user been submitted to the system to be aborted. The IF command enables a job to obey different commands depending on some condition being satisfied or not. Running an on-line job As described earlier an on-line job is initiated by a
LOGINcommand. Before
this command can be typed it may be necessary to input a
"Control-A" character (i.e. the "control" key is held down and
A pressed) in order to wake up the system. The system will
respond with an introductory message and the "invitation to
type" sequence. This takes the form: A command may now be typed followed by an "Accept" symbol. It is very easy to type when the system is not listening, so care must be taken to ensure that the invitation to type has been received. If no message is typed in response to the invitation then the system will eventually "time out" and produce a message TIMED OUT or CLOSED DOWN depending on whether the terminal was logged in or not. Control-A must be pressed to wake the terminal up again. (Note, that under the G3 Emulator 'TIME OUT' does not occur) If an error is made in typing a command then the _ symbol may
be used and has the effect of deleting the previous character.
__ would delete the previous two characters and so on,
e.g. If a message is badly in error then if "Control-X" is typed
the message Each command is obeyed as soon as the Accept key is pressed. If the command is in error a suitable message is output and the user can try again. When it is necessary to type a sequence extending beyond one line the Accept key must be pressed after each line. 'Newline' and 'Carriage Return' characters are never used. Sometimes a command may be issued and it is required to halt its execution. This can be achieved by using the Break-In facility. If the symbol Control-A is pressed then the current action of the system is halted and control returned to the console. The exact effect of the Break-in depends upon the command being obeyed:
After cases 2 and 3 the console is left in BREAK IN context.
A variety of commands can then be input following the
invitation to type, e.g. an EDIT might be performed to correct
a program text in error. The Break-in is terminated by the
single command In the case 3 only the Break-in may be terminated and the
original instruction resumed by the command Note that if a job with a core image is broken-in on and QUIT is used, then the core image is deleted, if CONTINUE is used execution continues. Running programs under George 3 A large number of commands are required to run a typical program; programs are therefore almost always compiled and run using a suitable macros. One of the most important features of George 3 is that a program does not require real peripheral devices to be available to it when it runs; peripherals can be simulated by files in the filestore. Typically, a George 3 system runs several programs concurrently and nearly all these programs will require to output to a line printer; it would be uneconomic to have many line printers dedicated to these programs since they would stand idle much of the time. A better solution is to accumulate output from a program in a file and then list this file on a line printer when the program has finished. In this way each job drives a real line printer flat out for a short period of time only and two line printers are capable of printing the output from a large number of jobs. For input peripherals:
For output peripherals:
Checking the progress of a job If the system breaks for any reason, jobs running at the time of the break are automatically rerun. Certain steps within a job may not be repeatable (either because they fail or, worse, cause corruption) so it is important to be able to detect rerunning. Also many jobs contain several logical steps (e.g. an edit followed by a program run). It is often pointless (and wasteful) carrying on with the later stages of such a job if one of the earlier stages fails. |