Section 5.2

Monitoring on Program Events

Contents

5.2.0.1 Program failures - default action and printing
5.2.0.2 Optional Events
5.2.1 Signals
5.2.2 Jumps
5.2.3 Overflow
5.2.4 Time
5.2.5 Unrounded floating point
5.2.6 Transfers - drum and peripherals
5.2.7 Monitoring in Style 7
5.2.8 Urgency
5.2.9 Impermissible Operand
5.2.10 Program failure
5.2.11 Weak reservations
5.2.12 Quick jumps

5.2.0  Monitoring on Program Events

There are several circumstances under which the machine, when obeying an instruction will interrupt (and hence cause an entry into OMP.) This instruction is not completed and no results are written away. Interruptions of this sort are called program events; the term program failure (prog fail) is used to distinguish unanticipated program events.

Following the interruption, the OMP Kernel makes a partial analysis of the circumstances, taking notice of 3-address unreplaced 150 instructions and implementing *OWN monitoring. All further analysis and action is then left to an OMP job called the Interpreter, thus all monitoring actions except *OWN require at least one drum reference. For *OWN (see 5.4)

5.2.0.1    Program Failures

Unanticipated program events (program failures) which may occur are:

  Event Message
   (i) Impermissible operand IMP.OPER
  (ii) Illegal instruction ILL.INST
 (iii) Writing with OVR set W.W.OVR
 (iv) Reservation violation RES.VIOL
  (v) Peripheral violation PER.VIOL

(vi) and (vii).  If monitoring signals in Style 1 is on then jumping to a signal or obeying a signal is a program failure (if these were anticipated then monitoring signals in another style would be on) the messages being JUMP.SIG and HLTD.SIG respectively.

(viii) and (ix).  If monitoring floating point overflow in Style 1 or monitoring fixed point overflow in Style 1 is on and an appropriate instruction overflows then this program event is a program failure, the messages being FLT.OVR and FXD.OVR respectively.

When an instruction fails because of one of the above program events then OMP's default action in cases (i) to (iv) is to suspend, and in cases (v) to (ix) is to halt the job.  Information is then printed; on the Flexowriter appears the following

      jobname     Message

and if the job has no monitoring peripheral then also on the Flexowriter is printed on the next line the instruction (or string) causing the failure, but if the job has a monitoring peripheral then on it is printed the same message and the instruction (or string) together with the values of all replacers and modifiers.

If *IMP or *PFP or *PFM has been set then OMP enters the appropriate restart (see 5.2.9 and 5.2.10, 5.2.20 and 5.2.23)    [The manual has no paragraph 5.2.20 or 5.2.23 - Ed]

Examples of printout  (replacers and modifiers on mon per only)

(a)   PER. VIOL
      A617    116     0      (A1)             (A1) = 100
      A618    141.1Y  0       2       A2      (A2) = 420
      A619    142    (A4)    (A5)             (A4) = A530 (A5) = 128

This indicates that the drum region 522 to 649 extends beyond the reserved region

(b)   ILL.INST
      A401    130     0       0       0

(c)   RES.VIOL
      A239    04Y    (A27)    36      A28     (A27) = 4 (A28) = A300

Note that addresses outside reservations are printed as integers: address within reservations as integers relative to the datum point with an A in front.

(d)   RES.VIOL
      A247    04     (-1)     A36             (32767)

If the address being replaced is outside reservations it is indicated as above.

(e)   RES.VIOL
      5104

The control number is outside reservations.

5.2.0.2   Optional Events

    Section Style name
     (i) Signals and jumps to signals  5.2.1  *SIG
    (ii) Jumps  5.2.2  *JUM
   (iii) Floating point overflow  5.2.3.0  *FOV
   (iv) Fixed point overflow  5.2.3.1  *OVR
    (v) Drum and peripheral transfers  5.2.6  *DRU or peripheral name
   (vi) Impermissible operand  5.2.9  *IMP
  (vii) Program failure  5.2.10  *PFP or *PFN
 (viii) Timer overflow  5.2.4  *TIM
   (ix) Unrounded floating point  5.2.5  *UNR
    (x) Urgency of program  5.2.8  *URG
   (xi) Weak reservations  5.2.11  *WEA
  (xii) Quick jump  5.2.12  *QUI

Events (i) to (iv) cause interruptions if appropriate staticisers are found to be set when the event occurs (152 instruction see 3.15). Drum transfers are made to interrupt by setting the number of words reserved equal to 1 (the hardware cannot deal with a reservation of zero words and this means that single word transfers to or from drum address zero cannot be monitored.)  Transfers to or from a particular peripheral are made to interrupt by effectively removing the peripheral from the program's reservations.  Timer overflow is detected by the pre 150 instruction (see 3.15).

The necessary conditions are controlled by the object program (or possible the operator) using either 150/20 instructions or MONITOR directives.  For the optional events there is a choice of styles.  Style 0 usually means no monitoring or the program is allowed to monitor in "style 7" which means that the action is taken by the object program itself (see 5.2.7 - note that style 7 does not apply to *UNR and *URG.)

The following sections describe the standard styles of monitoring and which style is set when the program is initially entered (i.e. which is the default style).

It is possible that if a program is monitoring several events, the same instruction may call for several monitoring actions.  To deal with this, events (i) to (vii) are assigned a hierarchy - the order is that given with event (i) being low.  If a program is monitoring signals, jumps and fixed point overflow and a signalled jump instruction overflows the monitoring will (or at least may) take place in order. i.e. signals first, then jumps and then overflow.

In branched programs each branch sets its own monitoring styles, the monitoring applying to that branch only i.e. different branches may monitor the same event in different styles, except for transfers to the same peripheral or drum.  All branches are held up (suspended) only while OMPís action for the monitoring takes place.

Some monitoring information will be output only on the monitoring peripheral.  If it is disengaged the message on the Flexowriter asks for it to be engaged, e.g.

      jobname     ENGAGE   SPB*

If the job has no monitoring peripheral then the job is halted and a message is printed on the Flexowriter,

      jobname     NO   MON.PER

If the monitoring peripheral fails while OMP is outputting monitoring information, then OMP outputs a message on the Flexowriter informing the operator of the failure e.g.

      jobname     LPA   OMP   BUFFER FAIL

In most cases OMP will repeat the transfer and/or carry on outputting the monitoring information. If the failure is of Operator type then OMP disengages the device. The operator should carry out appropriate action (such as reload more paper if paper low) and then engage the device when OMP will repeat the transfer and/or carry on outputting the information.

If the Flexowriter fails NL is output and the message repeated.

5.2.1   Monitoring on Signals

Cause of interruption: the program has attempted to obey or to jump to a word which has a zero signal bit.

Style 0 - No monitoring. i.e. a signalled instruction would not cause an interruption and would be obeyed as if not signalled.

Style 1 - (Default Style). The program is halted and the failure message HLTD.SIG or JUMP SI& is printed as described in 5.2.0.1 ; in this case this program event is a program failure. Note that RUN (see 5.7.3.3) will cause the job to continue.

Style 2 - Jumps to signals are ignored (by OMP). Details of each signalled instruction are output on the monitoring peripheral and the program continues. The information is output on one line in the following order:-

*S, Control number, function, effective X-address, effective Y-address, Z-address (3-address instructions only) - and: then any addresses written to, followed by their new contents, in octal.

A monitoring peripheral is necessary.

No printing takes place for 140, 141, 142 or 143.

Style 7 - Jumps to signals are ignored (by OMP). For details of style 7 monitoring, see 5.2.7

5.2.2   Monitoring on Jumps

Cause of interruption: The program has attempted to obey a jump instruction which would have been successful.

Style 0 - (Default style). No monitoring.

Style 1 - This is similar to monitoring signals in style 2, the output being preceded by *J instead.

A monitoring peripheral is necessary.

Style 2 - When monitoring in this style OMP keeps a record of the last 16 distinct jumps made by the program and outputs them on the monitoring peripheral (or some on the Flexowriter) if one of the following events occurs:

(a) Program is stopped because of program failure (see 5.2.0.1)

(b) A style of monitoring on jumps is set.

(c) The program is abolished.

When this style is first set, OMP annexes the last 16 words of the programís core store for the space in which to record the information. These words are not returned to the program when the style is changed; if the program subsequently resets this style however, the same 16 words are used.

The actual information, output is the function, the effective destination address and the control number; under the heading J TO FROM. Loops containing a single successful jump instruction will be represented by one entry in the list, with a number printed to the right of the standard information indicating the number of jumps that occurred. If this number is greater than 511, the number 511 will be printed. This Style slows the program down by a factor of 10.

Style 3 - This is the same as style 1, except that printing takes place on 86 instructions only.

Style 7 - For details of Style 7 monitoring, see 5.2.7. Monitoring on jumps is switched off on entry to the routine and restored by the 150/23 instruction - provided that the 150/23 would cause monitoring on jumps to be ignored.

5.2.3   Monitoring on overflow

5.2.3.0   Monitoring on floating point overflow

Cause of interruption:  The program has attempted to obey an instruction with one of the functions 90-95 or 102 and which would have overflowed.

Style 0 - No monitoring.

Style 1 - (Default Style ).  The program is halted and the failure message FLT.OVR is printed as described in 5.2.0.1, in this case this program event is a program failure. Note that RUN (see 5.7.3.3) will cause the job to continue.

Style 2 - This is similar to monitoring signals style 2, the output being preceded by *0.  A monitoring peripheral is necessary.

Style 7 - In addition to normal style 7 action (5.2.7) the address to which the instruction was about to write is stored in the Xó address position of the word containing the link.  OVR is not set on entry.

5.2.3.1   Monitoring on fixed point overflow.

Cause of interruption:  The program has attempted to obey an instruction which would have overflowed.

Style 0 - (Default style).  No monitoring.

Style 1 - The program is halted and the failure message FXD.OVR is printed as described in 5.2.0.1.  In this case this program event is a program failure.  Note that RUN will cause the job to continue.

Style 2 - This is similar to monitoring signals style 2, the output being preceded by *0.  A monitoring peripheral is necessary.

Style 7 - In addition to normal style 7 action (5.2.7) the address to which the instruction was about to write (or in the case of instructions with double-length write-back the first address) is stored in the X-address position of the word containing the link.  OVR is not set on entry.

5.2.3.2   Interaction between fixed and floating point OVR

There is no special floating point overflow register.  Floating point operations which overflow, set the ordinary overflow register like other instructions.  Floating-point overflow is only distinguishable from fixed-point overflow when it is being monitored.  In the case where both are being monitored it should be noted that both monitoring actions take place for each floating point operation which overflows - the floating point monitoring first.  If, for example, both are being Monitored in style 7 and the exit from the floating-point routine is a 150/23 instruction (q.v.) with *FOV in the X-address then the fixed point routine will be entered.  If *OVR is used the program will continue see also 5.2.7

5.2.4   Timer overflow

Cause of interruption:  Any interruption

Style 0 - (Default style).  The job is halted and the timer is set to a minute and the message TIME UP is printed on the Flexowriter only.  If RUN directive is given then the program continues.

Style 7 - The job is given another minute before the style 7 routine is entered.  The return to the program must be with an 87-instruction - and never with a 150/23 which would cause impermissible operand action.

Timer overflow event is not a real program failure and, for example *OWN (Style 7) or *PFP (Style 7) etc. would not be entered.

5.2.5   Unrounded Floating-point operations

There is no interruption.

Style 0 - (Default style).  From now on all floating-point operations are rounded.

Style 1 - From now on all floating-point operations are unrounded.

This facility is intended to be used to measure rounding errors.  Programs may be run with floating-point operations rounded and again unrounded.  Comparison of results then indicates the number of reliable significant figures.

5.2.6   Monitoring on External Transfers

5.2.6.0   Monitoring on drum transfers

Cause of interruption:  The program has attempted to obey a 141, 142 pair or a 150/50 instruction.

Style 0 - (Default action).  No monitoring.

Style 1 - Details of each drum transfer or 150/50 instruction are printed on the monitoring peripheral and the program continues.  The information printed is:

*D drum address, control number, mode, core store address, length of transfer, and the jump address if a 150/50.  Mode 2 means 150/50.

A monitoring peripheral is necessary.

Style 2 - Monitoring is on 150/50 only.  Ordinary drum transfers are not slowed down.

Style 7 - This is permitted.  See 5.2.7

Note that single word transfers referring to drum address zero cannot be monitored.

5.2.6.1   Monitoring on peripheral transfers

Cause of interruption: The program has attempted to obey a 140, 142 pair referring to the particular peripheral.

Style 0 - (Default style). No monitoring.

Style 1 - Details of each transfer (rewind is included) are printed on the monitoring peripheral and the program continues, the information printed is: programmers name of peripheral, control number, mode, core store address, length of transfer.  A monitoring peripheral is necessary.  If the monitoring peripheral is the peripheral being monitored, then the monitoring information will appear before the actual transfer.

Style 7 - This is permitted. See 5.2.7

In branched programs only one branch may monitor on external transfers to a particular peripheral or drum at any one time (see 5.3.20).

5.2.7   Monitoring in Style 7

This is set up with a 150/20 instruction (see 5.3.20); the X-address specifying the event and the Y-address the entry-point of the routine so that the program itself can. deal with the event. When the event occurs, OMPís action is to set the programís control number to Y and to store the link information in Y-1 (i.e. the modifier half contains the current (old) control number and the sign bit is the state of OVR). OVR is then cleared and OMPís action finishes by entering the routine at Y. If the program is branched all branches are held up only while OMP is storing the link information etc.

Return to the main program is then usually effected by using a 150/23 instruction, specifying the link address in the Y-address and the event in the X-address. The instruction

150  *SIG  A100  23

has the same effect as

87  0  A100

except that the 150 instruction causes monitoring on signals and lower events to be ignored while obeying the instruction in [A100]m.   Higher levels of monitoring remain active.  Thus if the program is monitoring OVR is Style 1 it would be halted if the instruction overflowed.

It is quite admissible to write

    150 *DRU A100 23

or  150 *PFP A100 23

both meaning obey the instruction in [A100]m with signals, jumps, overflow, peripheral transfers all monitored Style 0.

If the event being dealt with occurs in the Style 7 routine (e.g. a signal in a routine to deal with signals) the link back to the main program will be lost and chaos is likely to ensue.  The exception is that jumps are allowed in a Style 7 routine for monitoring on jumps (see 5.2.2).  It is insanitary for two branches to monitor the same event in Style 7 with the same entry-point.

5.2.8   Urgency of Program

The normal time-sharing system on Orion ensures that all jobs within the machine have their fair share of time - in general arranging peripheral-limited jobs at the top of priority list and mill-limited jobs at the bottom. For certain applications, however, it is desirable for this to be overridden either by a 150/20 instruction or a Basic Monitor sequence in the program or by the operator typing a Monitor directive (event *URG) on the Flexowriter. The styles are:

Style 0 (Default style). Program reverts to its natural place in the time sharing system.

Style 1 The program is treated as baseload and goes to the bottom of the priority list.

Style 2 The program is treated as urgent and goes to the top of the priority list.

If there is more than one program of urgency 1 or 2 they will be time-shared among themselves in the normal way. Different branches of the same program may have different styles of urgency but a new branch is given the style of branch 1 , not style 0.

A message jobóname URG 0 1 or 2 is printed whenever the style is changed.

5.2.9   Monitoring Impermissible Operand.

Cause of interruption: The program has attempted to obey an instruction containing an impermissible operand.

Style 0 - (Default style). The program is suspended and the failure message is printed as described in 5.2.0.1.

Style 7 - In addition to the normal Style 7 action (see 5.2.7} the write back address is stored in the X-address field (not for failing 150ís) and the string count, modulo 128 (this is 1 unless a compound instruction) in the Function position of the link word. If the program returns with 150/23 with X=*IMP then the program gets suspended as usual, unless the program is monitoring on program failure, in which case that routine gets entered.

The following function cause impermissible operand action.

 (a) 40-45, 95  division by zero.  Also 101
  90-95, 97, 103  non-standard floating point operand
  100  incompatible data and radices
  125  x* < 0
  142 following 140 or 141  if Y=0 or >32767
  150/2  being in closed down state
  150/3  Y>1
  150/4  X>5 or Y not correct
  150/10  Y>6
  150/13  Y>3
  150/15  Y<-1 or Y>8+n
  150/16  impermissible style or Y=0 or Y>20
  150/17  X>1
  150/20  X not recognised event
  150/21  Impermissible code number
  150/22  X not for an output device
  150/23  X not a recognised event
  150/24  X=0 or X>7
  150/30  X not a meaningful programmers name
  150/31  Y>3 or X for reserved tape deck or output device
  150/33, 34 or 35  Impermissible document name or X not meaningful
  150/36  Peripheral not the same
  150/40, 42  X not for a tape deck
  150/41 or 44  X not for a tape deck or impermissible doc. name
  150/43  Y>1 or X not for a tape deck
  150/50  Transferring zero words
  150/51  X=0 and y=0, or referring to SBIP not associated with program

5.2.10 Monitoring on Program Failures

Cause of interruptions: The program has attempted to obey an instruction which would normally prevail and cause suspension or halting as described in 5.2.0.1.

Style 0 - (Default Style). The program is suspended or halted and the failure message is output as described in 5.2.0.1

Style 7 - In addition to the normal Style 7 action the write back address (not for failing 150ís) and the string count, modulo 128 (this is usually 1 unless it is a compound instruction) is stored in the X-address and Function fields respectively of the link word.

Monitoring on program failures is of two forms *PFP or *PFN. If the job has a monitoring peripheral, then in the first case then the failure message is output to the monitoring peripheral before entering the Style 7 routine whereas in the second case no printing takes place before entering. No message appears on the Flexowriter.

If the routine exits with a 150/23 with X=*PFP or *PFN, then if the reason for the progfail was one of the cases (i) to (v) see 5.2.0.1 then the normal printing will take place (again in the case of *PFP with a monitoring peripheral) and the program will be suspended (halted if peripheral violation). Since 150/23 with X=*PFP or *PFN says ignore all monitoring while obeying the instruction, the program may continue with no printing taking place if the reason for the progfail was one of the cases (vi) to(ix).

Switching on or off of either of *PFP or *PFN switches off the other.

Note that because monitoring on program failures may now be set up, the manual in some places notably Sections 2 and 3, is not strictly accurate. Where it states that the program will be suspended due to reservation violation, impermissible operand etc. it is now true to say that reservation violation action etc will occur i.e. if these failures are being monitored the Style 7 routine will be entered, otherwise the standard action of suspension etc will occur.

5.2.11 Weak reservations *WEA (see 5.3.4)

A program (job) can switch on this condition with

150 *WEA 1 20

and then can read (but not write) outside its reservations.

The condition is switched off by

150 *WEA 0 20

The general arrangement is that one program declaring itself the Master should have fixed datum point and other programs declare themselves subsidiaries.  In general each will have two or more buffers and communication between the Master and subsidiaries is via 150/4 instructions and the masterís interrupt routine.  Subsidiaries know where to look for markers as to whether there is a buffer with information for them.  The master can scan the subsidiaries to see if they have information to deal with, the markers in this case being in fixed places relative to their datum point.

The master can be interrupted as described for 150/4 and also if a subsidiary is abolished or if a subsidiary restores monitoring conditions to standard.

5.2.12 Quick jump instructions *QUI

This facility is used to speed up programs by not checking the destination addresses of successful jump instructions. It is available only on installations with a suitable hardware modification.

Style 0 - (Default style) Destination addresses are checked for being within reservations.

Style 1 - The program will not be checked on its jump address in a jump instruction. Thus a program jumping outside reservations will have a RES.VIOL at the location it has jumped to, rather than the jump instruction itself.