A monitoring file is created for every job as soon as it is started. GEORGE puts into this file a variety of information about the job. An indication is given of the time that each command starts execution with any comments and error messages that are generated while the job is executing. It is possible for the complete output from commands like LISTFILE to be sent to the monitoring file rather than being listed as a separate document. The monitoring file contains as complete a record as the user requires of the progress of his job through various stages. The major problem with making use of the monitoring file is that it can contain a large amount of information with very little of it relevant to a particular error. Controls are provided for selecting the information to be sent to the monitoring file and the part of this information to be printed.
The name given to the monitoring file is the same as the jobname but with a language code of B1B0 and a generation number of 1.
GEORGE divides the information being presented to the monitoring file into a number of categories. The user may select which of these are actually entered into the monitoring file and further select which of these categories get printed. The most important categories are described below.
An entry is made for each command obeyed; the entry consists of the time that the command is issued together with a copy of the command. For example:
09.05.55← JOB FRED,:NTBE34,JD(JT 30 SECS) 09.05.56← TI 20 09.13.59← EN 0
Most of the commands are likely to be abbreviated and it is, therefore, essential to be familiar with the possible forms of the main commands. Records of editing instructions are classed as commands.
An entry is made for each error detected in a command. For example, an attempt to erase a file without the necessary traps set would produce the entry:
ERROR IN ERASE IN PARAMETER 1 : TRAPS CLOSED
Errors while editing are classed as command errors. The errors reported to a MOP terminal are similar to those entered into the monitoring file in the COMERR category.
All output from LISTFILE and LISTDIR commands, which does not specify an output peripheral, is entered in this category. Thus the output from the command:
LISTFILE FRED
will be directed to the LISTING category of the monitoring file.
Messages in this category contain the clock time at which they were generated and normally contain the total time charged to the job at that point in minutes and seconds. Messages in this category are produced whenever a job starts or a program is loaded, deleted or has its core size changed. Also, a message is produced when a peripheral is on-lined or released. Some example messages are:
STARTED :NTBE34.MTJOB, 7MAY74 09.05.55 09.13.59 0.02 SIZE GIVEN 3072 09,14.01 0.03 DELETED,CLOCKED 0.01 MAXQ=35K, PT=105, USED 50K 09.14.12 FREE *CP0 4290 TRANSFERS 09.14.16 0.04 FINISHED
The lines 0.02, 0.03 and 0.04 given indicate the amount of time that has been used since the start of the job in seconds.
The main categories of interest to the user have been indicated above. There are a number of other categories but messages in these categories are less frequent and it is therefore simpler to consider these messages as belonging to a single remaining class. Some examples of other monitoring file entries are:
When a job is started initially, a default setting normally defines what categories of messages are to be sent to the monitoring file. A user may suppress information in one or more categories and prevent it being sent to the monitoring file by the TRACE command. In its simplest form the TRACE command just lists the set of categories to be sent to the monitoring file. For example:
TRACE LG,CE
This example specifies that all messages in the LOGGING (LG) and COMERR (CE) categories are to be allowed into the monitoring file.
The two special commands:
TRACE ALL TRACE NONE
define that all or a minimum tracing (defined by the Installation Parameter MINTRACE) of the messages are to be allowed into the monitoring file. Neither of these alternatives is particularly useful on most occasions. There is nearly always a need for some monitoring information although this should be kept to a minimum. A particularly useful form of the TRACE command is one in which the user specifies the categories to be omitted. For example:
TRACE ALLBUT,COMMANDS
Abbreviations are allowed for ALLBUT(AB) and the categories defined above. The above command could have been written:
TRACE AB,CM
This is probably the most commonly used form of the command. Although the important messages about the state of the job will be output, the great number of lines indicating commands obeyed will be omitted. Note, however, that if a command error occurs, there will be no indication of which command caused it, and this must be deduced from the error message.
The FULLTRACE command (D.8.3) may be issued at any point in the execution of a job. This is equivalent to TRACE ALL except that later TRACE commands will be ignored. It can be used as a diagnostic tool. Normally, a macro will limit the amount of information that is generated by it. The FULLTRACE command allows the user to get at this information. Even though all the monitoring information is sent to the file, it is still possible to print only selective parts so that the amount of output is not too large.
The main purpose of the ENDJOB command (D.2.2) is to terminate a background job. However, it has a secondary purpose which is to determine what is to happen to the monitoring file. There are two separate decisions to be made. The first defines which parts are to be listed while the second determines whether the contents of the monitoring file are to be retained in the filestore.
Selecting which parts are to be listed has a similar parameter form to the TRACE command. For example:
ENDJOB ALLBUT,COMMANDS
This will list the whole of the monitoring file apart from the commands. Note that it is only possible to list the information that is there. If the TRACE command had already stopped COMMANDS being sent to the monitoring file, there is no point in specifying this in the ENDJOB command also.
If no parameter is given in the ENDJOB command, it is equivalent to:
ENDJOB ALL
At the end of the job, after the desired listing has been produced, the monitoring file will be erased. It is possible to copy the monitoring file to a permanent file before erasure by adding a parameter of the form:
ENDJOB ALLBUT,COMMANDS,RETAIN(MFNAME)
The parameter RETAIN can be abbreviated to RT. This causes a complete copy of the monitoring file (not those entries listed) to be kept in the user's file MFNAME. For example:
ENDJOB NONE,RT(MFNM)
will suppress the listing of a monitoring file but keep a copy in MFNM. This could be useful to the remote user who wishes to interrogate his monitoring file from a MOP terminal and never requires a listing to be made at the central lineprinters.
The user should be careful not to remove the monitoring file listing completely for a background job as this tends to be the only record for the operator that the job has been completed.
The LOGOUT command which terminates a MOP job has parameters just the same as ENDJOB. Normally no record of a MOP job is required and, consequently, the default settings are for no monitoring information to be listed. If no parameters are specified, the default is:
LOGOUT NONE
However this still does not stop a minimal amount of logging information being output. If this is not required at a MOP terminal, the user should input:
REPORT CE LOGOUT
This can be helpful when the user is anxious to get on with other terminal work.
In most cases, the output produced by the compiler will contain all the information useful to the user. Compilation errors will be listed and tracing information will be output if the program fails. The monitoring file is mainly useful for:
Command errors all have the general form:
ERROR IN command IN macro IN .... : error message
Appearances of this message in the monitoring file almost always signify some kind of error. Some typical ones are:
(1) THIS IS NOT A COMMAND
Mistyped command; no space or ',' immediately after the command name; reading input as commands.
(2) VERB FORMAT ERROR
As above (1).
(3) filename DOES NOT EXIST
Mistyped filename; file does not exist; wrong directory level.
(4) TRAPS CLOSED
The user does not have the correct traps to the file for the action he wishes to do.
(5) YOU DO NOT HAVE THE PRIVILEGE TO USE THIS COMMAND
Often indicates that the user's CONTEXTA has been removed.
This category contains much standard and uninteresting information but it does contain reports on the system resources that have been used by the job. The user should use this to reduce his JOBTIME to the minimum required and also his core utilisation.
There are a number of standard messages in the categories DISPLAY, HALTED, DELETED and FAILED which can occur when running a job. Many of these are given as two character HALTS or DELETES when a program ends and an explanation of those from standard systems is given in J.5. Most other messages are self-explanatory and some of the more common are explained more fully below.
(1) END OF MACRO
Given every time a job exits from a macro.
FREE peripheral channel, count TRANSFERS
Given every time a peripheral channel to a program is released. Count gives the number of transfers on that channel. For a basic file, this is the number of records written or read and can be very useful in ascertaining, for example, how many records (if any) of data were read before a program failed. For example:
FREE *CR0,71 TRANSFERS
indicates that channel *CR0 read 71 records (or cards). A value of 0 transfers indicates that the channel had never been read from or written to.
Disc and magnetic tape transfers are more difficult to interpret as various housekeeping actions (opening, closing, extending) count as transfers. A zero value indicates the channel was never accessed.
(3) The monitoring file is also used to pass information to the users about, for example, system changes, imminent shutdowns, etc. These appear almost at the end of the monitoring file, after the ENDJOB or EJ command.
(1) JOB ABANDONED : JOBTIME EXCEEDED
Insufficient JOBTIME has been given or program has got into a loop.
(2) TIME UP
Insufficient TIME given for a program or it has got in a loop. By allocation of more TIME the job can be continued.
(3) ILLEGAL : RESERVATION VIOLATION
Given when a program tries to address a word outside its address space. In a user's binary program, this often means an array is being incorrectly accessed. This message can also occur during a FORTRAN compilation and TASK should be given a larger MZ value to overcome this.
(4) FILE peripheral channel EXHAUSTED
Given when a program reads off the end of a file on peripheral channel. For a user program this means insufficient data has been supplied. For cases where a source file for a compiler has not the correct terminator this message can also occur, and TASK will simulate the correct terminator. Provided no other errors exist the compilation will be alright.
(5) OUTPUT peripheral channel LIMIT
Given when a program has generated too many records for the LIMIT of the output file on peripheral channel. The default setting is set by ACL and can be overridden by use of the LIMIT qualifier when assigning the file.
Several system macros, notably TASK and NUTS, give additional messages to the monitoring file. These are intended to inform the user of the start and finish of the various phases of the job and enable the user to diagnose failures more easily. Such messages are usually preceded by a character (for example #) repeated several times, or are boxed round by lines of *'s.
In the TASK system for example, TASK indicates the various default parameter settings by such messages and also lists out all the parameters for that call of TASK. The assigning of files to the compiler and consolidator and the beginning of compilation and consolidation are also marked by messages to the monitoring file. The result of the compilation and consolidation is sent to the monitoring file (and also the compilation listing), enclosed in *'s so that it clearly stands out. Error messages are similarly highlighted as are the beginning and ending of the run of a binary program produced. Users are strongly advised to study these messages and to gain an understanding of what they mean in order that error diagnosis can be achieved more easily. This is especially relevant when advice on errors is sought over the telephone when lack of user understanding can seriously hamper the ability of the ACL staff to help the user.
A sample monitoring file is given with comments in the following listing. This details the running of the standard TASK job given in Part B.
//LISTING OF :NTBE34.FOR-GWRMOP(1/B1B0) PRODUCED ON 6NOV74 AI 15.24.20
//OUTPUT ON SRC 6A G4MK77E UNIT U14 BY JOB ':NTBE34.FOR-GWRMOP' on 6NOV74 AT 15.24.21
DOCUMENT :NTBE 34.FOR-GWRMOP(/B1B0)
STARTED :NTBE34,FOR-GWRMOP, 6NOV74 15.16.10 TYPE:BACK
15.16.10← RJ FOR-GWRMOP,TASK,PARAM(FORTRAN,*CR FRED,,,,,,,,,, (,,,,,,,,,,,),,,,,,,,,-
MOPEJGJWMOP),JD(MZ,JT,MQ,MT,7T,)
15.16.10← TASK FORTRAN ,*CR FRED,,,,,,,,,, (,,,,,,,,,,,),,,,,,,,,MOPEJGWRMOP
15,16.10← #
15.16.10← # TASK MACRO MK 4.2 - LISTFILE :NEWS,TASK FOR LATEST ENHANCEMENTS - 28.10.74
15.16.10← #
15.16.10← IF MOP,GO 9ACL1RJ
15.16.10← 9ACLX TA CE,OL,OJ,PM,LS
15.16.17 0.01 USED URGENCY M | TASK SYSTEM LOADED
15.16.23 0.01 SIZE GIVEN 9216 SPARSE
DISPLAY : 44
MOPEJGWRMOP
###### ANALYSE AND LIST PARAMETERS FOR THIS TASK | PARAMETERS FOR THIS TASK
FORTRAN
*CR FRED
###### SET UP DEFAULT FILENAMES AND RETRIEVE FILES | DEFAULT FILENAMES SET UP
====== DEFAULT : #CR FRED-DAT
====== DEFAULT : TI 30 SECS
###### ASSIGN FILES FOR COMPILATION | COMPILE PROGRAM
15.22.26 0.04 SIZE GIVEN 100352 SPARSE
###### BEGIN COMPILATION
DISPLAY : C2
15.22.35 FREE *CR1 ,4 TRANSFERS
15.22.57 FREE *CR0 ,13 TRANSFERS
DISPLAY : COMPILED 100 //FORT EC
****************************************
COMPILATION OK
****************************************
15.23.01 0.05 SIZE GIVEN 30720 SPARSE
0.05 Q=15K PT=78:HALTED : LD
15.23.01← IF HALTED(LD),RM ,PARAM(,,,,,,,,,,,,M,N,O,P,Q,R,S,T,U,V,W)
15.23.01← RM,PARAM(,,,,,,,,,,,,M,N,O,P,Q,R,S,T,U,V,W)
###### ASSIGN FILES FOR CONSOLIDATION
15.23.01← OL *DA2, (26.SUBGROUPSRF8)
15.23.05 FREE *DA63,8 TRANSFERS
###### BEGIN CONSOLIDATION | CONSOLIDATE PROGRAM
15.23.18 0.06 SIZE GIVEN 38912 SPARSE
15.24.04 FREE *DA1 ,11 TRANSFERS
15.24.05 FREE *DA2 ,65 TRANSFERS
15.24.08← QT FREE 5000
****************************************
*##### CONSOLIDATION OK
****************************************
15.24.11← ER 1
###### ASSIGN FILES FOR RUN OF BINARY | ASSIGN FILES FOR BINARY
15.24.11← AS *CR0,FRED-DAT
15.24.11← TI 30 SECS
15.24.11← SP @T,(8)
15.24.11← SP @V,(EN)
15.24.12 FREE *LP63,29 TRANSFERS
15.24.13 0.08 SIZE GIVEN 5120 SPARSE
0.08 Q=5K PT=96:HALTED : LD
15.24.13← | BINARY LOADED
15.24.13← TA CE,OL,OJ,PM
15.24.13←
15.24.13← ###################################
15.24.13← #
15.24.13← ###### RUN OF BINARY BEGINS
15.24.13← #
15.24.13← ###################################
15.24.13← #
15.24.13← EN | BINARY ENTERED
15.24.16 FREE *CR0 ,1 TRANSFERS
15.24.17 FREE *LP0 ,154 TRANSFERS
0.09 Q=5K PT=100:DELETED : 00 | BINARY ENDS
15.24.18 0.09 DELETED,CLOCKED 0.01 MAXQ=35K, PT=100, USED 5K | BINARY DELETED
15.24.18← TA CE,OL,OJ,PM
15.24.18← #
15.24.18← ###################################
15.24.18← #
15.24.18← ###### RUN OF BINARY ENDS DELETED 00
15.24.18← #
15.24.18← ###################################
15.24.18← #
15.24.18← TA CE,OL,OJ,PM
15.24.18←
15.24.18← IF PRE(MOPEJ), EJ
15.24.18← EJ
The monitoring file gives information about the resources used by the job. Two main types are logged, core store (in words or K words) and central processor (CPU) time (in seconds).
(1) When a binary program is loaded or changes its virtual store size a message is given of the form:
h t SIZE GIVEN s SPARSE
The string h is the time at which the message occurred. The string t is the CPU time used by the job so far. It is the sum of the time used by the binary program(s) and by GEORGE on behalf of the job. This is the value that is checked against the TIME requested for the program and the JOBTIME requested for the job (or the default settings). s is the virtual store (or size) allocated to the program. This value is limited by any MAXSIZE requested for the program (or its default value) and any expansion beyond this value will give an error. For dense programs the word SPARSE is omitted from the message.
An example is:
10.37.29 0.08 SIZE GIVEN 5120 SPARSE
(2) When a binary program HALTS or DELETES a message is given of the form:
t Q=qK : HALTED : xx
The string t is the CPU time as before and xx is a many-character message giving the reason for the program stopping.
The string q is the quota of the program when it stopped and is the actual core store occupied by the program when it was running. It is less than or equal to the virtual store required by the program.
An example is:
0.05 Q=15K : HALTED : LD
(3) When a binary program is deleted, a message is given of the form:
h t DELETED CLOCKED c MAXQ=mK, PT=p, USED uK
The strings h and t are as previously defined. The string c is the CPU time used by the binary program alone. It does not include the time used by GEORGE on behalf of the job which is given by the value t-c.
The string m is the maximum quota that the binary program occupied during its execution. In future this may be controlled in a similar manner to the MAXSIZE of the program.
The string p is the number of page-turns the program did in mapping the virtual store of the program on to the quota of core store occupied by the program.
The string u is the virtual store that had been accessed at the time of the deletion of the program and is less than or equal to s in the preceding (1) message. Note that if the program has reduced its virtual store this can be less than m and q .
An example is:
10.37.38 0.08 DELETED,CLOCKED 0.05, MAXQ=35K, PT=105, USED 50K
(4) At the end of a job, a message is given of the form:
MAXIMUM ONLINE BS USED b KWORDS h t FINISHED : l LISTFILES
The strings t and h are as defined previously. The string b is the maximum amount of backing store used by the job. The string l is the number of LISTFILES (including one for the monitoring file) issued by the job.
Messages in (4) above give the total time used by the job and hence a minimum value for JOBTIME that it requires.
Messages in (3) give the time used by the program and hence the value of TIME required. Since t is cumulative, it must be differenced with the value at the time the binary was loaded to give the minimum value of TIME required. This is usually slightly more than the value c but since the latter does not include the time used by GEORGE, it is unwise to rely on the latter as an indicator of the TIME required.
Messages in (1) give the virtual store requested by the job and if the maximum value given in these messages is greater than the default setting of MAXSIZE, this gives the value of MAXSIZE required by the job. This is especially involved when assessing the MAXSIZE for a job run under TASK since the largest value may be either in the compiler or the consolidator. TASK will usually indicate when a larger MAXSIZE is required.
In message (3) the u value gives the amount of virtual store accessed by a binary program and can be used when running programs with large arrays to assess the minimum size required to run the program with small data sets that do not require all the storage allocated.
The main inefficiency detectable from the monitoring file is that due to page-thrashing. The value of q gives the quota or core store required by the program and the lower this is, the more efficiently the program will run on the I906A. A value of >40K is large. Where q approaches the value of u, it means that the program is accessing its whole virtual store and could possibly be restructured to improve its performance (see Part X.5).
The more critical inefficiency is when the value of q reaches the maximum permitted and the page-turning rate increases. This can considerably degrade the performance of the 1906A and is shown for p>1000 by a value of p/c>100. This will result in long elapsed times for the program and users should consult the Program Advisory Office if this occurs.
HALT/
DELETE/
DISPLAY MEANING
ZZ Compilation failed.
EC Successful compilation of segment.
** End of compilation of a segment or program with no consolidation by TASK.
C2 FORTRAN compiler requires default program description.
EF Compiler read off end of source file.
CR,TR,FR Compiler requires source file on channel type stated.
!c Where c is any character - TASK failure.
ST Insufficient core store for the compiler.
FI End of successful compilation (not under TASK).
CE Checksum error when reading semicompiled.
OK End of successful PLAN compilation (not under TASK)
with no automatic consolidation.
LD Binary loaded after consolidation.
MD Segments missing in consolidation.
HH Binary consolidated into BIN file instead of core.
YY Consolidation fail - see lineprinter output for reason.
!c When c is any character - TASK failure.
ST Consolidator requires more core store than is available.
ER Corrupt semicompiled or >4096 words of lower data
- see lineprinter output for message.
PE Parameter error on manual consolidation.
** End of consolidation to BIN file by TASK.
PX Error in automatic consolidation, parameters from compiler
- semicompiled usually corrupt.
CE Corrupt semicompiled - checksum error.
RL A file used by consolidator has been removed from the system.
HALT/DELETE MEANING
00 Successful run of binary - FORTRAN.
AH Successful run of binary - ALGOL.
HH Successful run of binary - PLASYD.
EE Execution error.
PM PMD(Post Mortem Dump) needed after error - ALGOL,
DF Successful PMD taken after HALT PM.
CR,CP,LP
,TP,TR,FR Binary requires a peripheral of type given in HALT.
,FW
ST Program stack requires more store - ALGOL.
Xc Where c is any character - Program has read a non-numeric
character c in a numeric field of input.
QQ Attempt has been made to use a missing segment (ie after consolidation has displayed MO).
nn Where nn is in the range 0-99. FORTRAN PAUSE statement.
Where nn is in the range 20-29. Incorrect or no entry point. No MASTER SEGMENT in FORTRAN.
EX FORTRAN program has done a CALL EXIT.
SZ Error in reading or writing of FORTRAN direct access files or error in DEFINE FILE statement.
K1 Parity error on reading disc file.
G2 Failure of integrity code on disc file.
LD Program has gone wrong and has obeyed word 19.
Note that a large variety of other messages are possible due to halt or delete instructions being either inserted in the program by the user (particularly when using an assembly language), or included in a program or subroutine packaged employed by the user. In the latter case, the messages will be documented in the manuals relevant to the system in use.
HALT/DELETE MEANING ** TASK ending after parameter errors or about to execute a user macro. ER Usually means a system has ended in error. OK Successful end. PM Post Mortem taken after system failure.