Contact us Heritage collections Image license terms
HOME ACL Associates Technology Literature Applications Society Software revisited
Further reading □ OverviewPaper 1Paper 2Paper 3Paper 4Paper 5Paper 6Paper 7Paper 8Paper 9Paper 10Paper 11Paper 12Paper 13Paper 14Paper 15Paper 16Paper 17Paper 18Paper 19Paper 20Paper 21Paper 22Paper 23Paper 24Paper 25 revPaper 25Paper 26Paper 27Paper 28Paper 29Paper 30Paper 31Paper 32Paper 33Paper 34Paper 35Paper E
ACD C&A INF CCD CISD Archives Contact us Heritage archives Image license terms

Search

   
ACLLiteratureProgress ReportsTechnical Papers :: Literature: FR80 Technical Papers
ACLLiteratureProgress ReportsTechnical Papers :: Literature: FR80 Technical Papers
ACL ACD C&A INF CCD CISD Archives
Further reading

OverviewPaper 1Paper 2Paper 3Paper 4Paper 5Paper 6Paper 7Paper 8Paper 9Paper 10Paper 11Paper 12Paper 13Paper 14Paper 15Paper 16Paper 17Paper 18Paper 19Paper 20Paper 21Paper 22Paper 23Paper 24Paper 25 revPaper 25Paper 26Paper 27Paper 28Paper 29Paper 30Paper 31Paper 32Paper 33Paper 34Paper 35Paper E

Paper No 4: FR80 Logging System

J M Rushby and R W Witty

9 April 1975

1. INTRODUCTION

A logging facility is to be implemented on the FR80 in order to maintain an automatic record of work performed by the machine. The log will reside on the FR80 disk and will be periodically dumped onto magnetic tape. These tapes will be regularly processed by the 1906A in order to determine the amount of FR80 system resources consumed by each plotting job, and so provide for the accurate billing of each FR80 user. Initially, the log will record only the barest minimum of information consistent with providing this service. At a later stage, the logging of additional data may be considered desirable. Further possibilities include the provision of a facility within the FR80 itself for interrogating the logged data in order to discover, for example, the progress of a particular user job.

2. OVERVIEW OF THE LOGGING MECHANISM

Data will be written in the log by a special FR80 monitor program, to be known as the LOGGING MONITOR. The data which is to be logged will be conveyed to the logging monitor by means of special monitor commands, to be known as LOGGING COMMANDS. These commands will have the same format as ordinary monitor commands. The name of the command will indicate to the logging monitor the type of logging record which is to be created; while the parameters to the command will supply the data which this record is to contain. The activity of invoking the logging monitor and supplying it with data is to be known as a LOGGING JOB.

So that each plotting job can be correctly clocked in and clocked out of the FR80, it will be necessary to both precede and follow every plotting job with a logging job. These jobs will be termed the LEADING and TRAILING logging jobs, respectively. When the stand-alone FR80 system (ie not LOADGO) is in use, the execution of these logging jobs will be the responsibility of the FR80 operators. Under the LOADGO system, however, it will be the duty of the Graphics Packages to perform this task. It is the purpose of this paper to give details of how this is to be done.

3. LOADGO TAPE FORMAT

The format of an FR80 LOAD GO tape was defined in FR80 Technical Paper 2. We briefly review this information here.

On a LOADGO tape, the data for each job is preceded by two header records and followed by a single filemark. The first header record contains the name of the monitor program which is to process the data, while the second header record contains a set of monitor commands which are to be obeyed by the chosen monitor program before it begins processing the data records. All graphics packages which intend to use the ACL FR80 should already be generating output in this format.

Naturally, logging jobs must also conform to this standard format, but since all the data for a logging job is contained in its monitor commands, the provision of data records would seem to be unnecessary for this class of job. Unfortunately, LOADGO is unable to process jobs which contain no data records. In order to circumvent this difficulty, we will require that each logging job contains a single data record. The contents of this record are irrelevant since they will never he examined.

In summary, an FR80 LOADGO job should now conform to the following format:

           1a FIRST HEADER RECORD     (Names the logging monitor)
LEADING    1b SECOND HEADER RECORD    (Supplies logging commands)
LOGGING    1c DUMMY DATA RECORD 
JOB        1d FILEMARK                (Terminates leading logging job) 
           2a FIRST HEADER RECORD     (Names the FR80 Displayer)
PLOTTING   2b SECOND HEADER RECORD    (Supplies monitor commands)
JOB        2c ....................
           2c GRAPHICAL DATA RECORDS  (graphical data may be several records)
           2c ....................
           2d FILEMARK                (Terminates the plotting job)
           3a FIRST HEADER RECORD     (Names the logging monitor)
TRAILING   3b SECOND HEADER RECORD    (Supplies logging commands)
LOGGING    3c DUMMY DATA RECORD
JOB        3d FILEMARK                (Terminates trailing logging jobs)
         

We draw the reader's attention to the following points:

  1. Contrary to the specification in FR80 Technical Paper 2, the graphical data records are no longer to be preceded by a filemark. This is because LOADGO is unable to accept a filemark immediately after a header record.
  2. Although the MAXIMUM length of a LOADGO header record is fixed at 256 FR80 words, shorter records are acceptable and so we no longer require that header records be padded out to the maximum length. However, it is inadvisable to generate records shorter than, say, 32 words as this can cause problems with the tape decks.
  3. Remember that the first header record is written in 6-bit ASCII packed three characters to a word, while the second header record uses 8-bit ASCII with only one character word(right justified) in each word. The data in each header record is terminated by an all zero word and any padding words should also be all zero.

4. THE FIRST HEADER RECORD OF THE LOGGING JOBS

The first LOADGO header record of each logging job supplies the name of the logging monitor. This name is SYSLOG. Thus the first header record of a logging job should have the symbolic form:

   Word 1   Word2   Word 3   Word 4 ... Last Word
    ***      SYS     LOG        all zero

In 6-bit ASCII, this becomes (in octal)

   Word 1   Word2   Word 3   Word 4 ... Last Word
   525252   233123  141707   000000 ... 000000

5. THE LOGGING COMMANDS

There are only three logging commands available to graphics packages. They are GSTART, GEND and GCOM. The set of commands in each logging job is terminated by the standard command GO.

5.1 The Commands of the Leading Logging Job

The minimal set of commands which may appear in a leading logging job consists of a GSTART followed by GO. Optionally, one or more GCOM commands may appear in between these two commands.

5.2 The Commands of the Trailing Logging Job

In this situation, the minimal set of commands is a GEND followed by a GO. Again, one or more GCOM commands may optionally appear, but in this case they must precede the GEND command.

5.3 The Logging Commands in Detail

The general form of a logging command is the same as that of any other monitor command. That is the command name appears first, followed by a slash, followed by zero or more arguments. Arguments are separated from one another by commas and consequently, no argument may contain a comma embedded within it Every command is terminated by the special character code 215 (octal), which we will represent here by the symbol &. The arguments of a command must appear in the correct order. In exceptional circumstances, an argument may be omitted altogether, but any commas which would normally appear before or after the missing argument must remain. Any leading blanks which appear in an argument will be ignored, while trailing blanks are not allowed. We now describe the individual commands in detail.

(1)  GSTART/ <user name> , <job name>, <camera> ,<package>, <machine> &

The first two arguments are character strings and the remaining three arguments are all decimal number strings:

  1. <user-name> consists of at most 6 characters and is a name by which the user is known to the ACL accounting system. In the case of a 360/195 user, the <user name> should be constructed by appending the two-character user ID to the four-character ACCOUNT NAME. For example: AZ05A3. In the case of a 1906A user, the <user name> is formed by deleting the colon from the front of the 1906A USERNAME and truncating the remainder to six characters. For example: :GSIN18 becomes GSIN18, and :OPERATORS becomes OPERAT.
  2. <job name> consists of at most 12 characters and is a name assigned by the user to identify a particular job. For example: JMRPLOT.
  3. <camera> is a single digit specifying the camera used by the job. The numbering scheme used by the 1906A SPOOL should be employed here, namely:
    1. 8020 camera, 16mm colour film
    2. 8020 camera, 16mm B and W film
    3. 8020 camera, 35mm colour film
    4. 8020 camera, 35mm B and W film
    5. 8021 camera
    6. Microfiche
    7. Hardcopy (less than 4-up)
    8. Hardcopy (4-up or more)
  4. <package> is likewise a single digit specifying the identity of the package which generates the job. Again the same numbering scheme as that used by the 1906A SPOOL should be employed. That is:
    • 0 SMOG
    • 1 SPROGS
    • 2 GROATS
    • -1 'other'
  5. <machine> is a single digit which specifies the machine on which the job was run. The scheme used is:

    • 0 ACL 1906A
    • 1 RUTHERFORD 360/195
    • -1 'other'

    Thus if user :GSINI8 issues a 1906A 'SMOG' job which has jobname XYZPLOT, and which is intended to produce 4-up hardcopy on the FR80, the following command would be issued by the leading logging job:

    GSTART/GSINI8 ,XYZPLOT,8,0,0&
    
(2) GEND/ <sub-frames> , <frames> &

Both arguments are decimal number strings:

  1. <sub-frames> should be the same statistic that would be placed into word 28 of the job information bucket of the 1906A SPOOL; that is the number of advance film orders issued by the job.
  2. <frames> is similarly the statistic that would be placed into word 29 of the SPOOL job information bucket. That is, for microfiche and hardcopy it is the number of frames output, if known, otherwise it is zero.

Thus a many-up hardcopy job which plots 107 frames of output with 426 sub-frames, should cause the following command to be issued by the trailing logging job:

GEND/426,107&
(3) GCOM/ <comment> &

This command allows a comment to be written in the log. The argument may be any character string. The authors of this paper should be consulted if any graphics package intends using this facility.

(4) GO/&

This command takes no argument and merely serves to terminate the set of logging commands in a particular job.

6. EXAMPLE

Consider a 1906A SPROGS job, generated by user :GSINI8 with jobname XYZPLOT. The job uses 35mm colour film and plots 18 frames of output. A 7-track tape produced by this job would have the format:

          1a  ***SYSLOG 
LEADING   1b  GSTART/GSIN18,XYZPLOT,3,1,0&GO/&
LOGGING   1c  Dummy Data Record
JOB       1d  Filemark
          2a  ***FCFO 
PLOTTING  2b  CAM/3&TAPE/5&GO/&
JOB       2c  Graphical Data Records 
          2d  Filemark
          3a  ***SYSLOG 
TRAILING  3b  GEND/18,0&GO/&
LOGGING   3c  Dummy Data Record 
JOB       3d  Filemark
⇑ Top of page
© Chilton Computing and UKRI Science and Technology Facilities Council webmaster@chilton-computing.org.uk
Our thanks to UKRI Science and Technology Facilities Council for hosting this site