Notes on the Priorities of the Various Observing Programs

    Virtually all of the programs used in the antenna control and data 
acquisition run on Kronen.  This includes a few programs that have windows
on the Frankenheim screen: OBST, BEORGA, & FEORGA.

    Normally, interactive processes on Kronen have a priority of 4.  The
SMTSYS> windows and the xephem program, for example, run at priority 4.
Critical processes are given higher priority:

    Program	Priority
    FAHREN	18
    CONTROL	15
    MTWRITE	14
    FEORGA	 6
    BEORGA	 6
    OBSERVE	 6
    OBST	 5

Note, the on-line Chef program ("CLAS_OD") isn't in this list.  The thinking
here was that the observing came first, and data display has lower priority. 
(We might experiment with increasing its priority.  We could also bump the 6's
to 7's and OBST to 6, to preserve the relative order.) 

In VMS, jobs of equal priority compete equally with each other, and higher
priority jobs run before lower priority ones.  If a high priority job never
waits for I/O or something else, it will lock out any lower priority jobs.  VMS
may decide to add to the above "base priorities" in certain circumstances.  (I
don't know what the rule is, but I suppose certain I/O operations in progress
might benefit from a temporarily higher priority in order to free up the device
driver so that it can move on to other things.) 

The priority of any process in the system can be adjusted by an SMTSYS process
(if it has given itself SOMEPRIV privileges): 

	set process/priority=<n> <process name>

or

	set process/priority=<n>/id=<process id>

Here <n> is the desired base priority, and <process id> is the Pid.  The Pid 
can be found by looking at the (hexadecimal) number in the left column of the
SHOW SYSTEM output. It is also printed by FINGER.  The second form, always
works.  For the first one to work, the job must be in the same User Group. 
(OBST isn't in the same group as SMTSYS, but all of the rest are).  If no /ID
or <process name> is specified, the process executing the SET command is
affected. 

Ordinarily, the above priority allocation works adequately.  Occasionally,
SAVE_DATA backups seem to interfere and slow things down.  (This can happen 
during on-the-fly processing, as this really taxes Kronen.)  If you think
a SAVE_DATA is causing problems, you can try reducing its priority to 0 or 1.
(Use FINGER SMTSYS in another window to figure out which process is doing
the BACKUP.)  One can also pause the SAVE_DATA with 

	set process/suspend <process name>

and resume it with

	set process/resume <process name>

Note that CTRL-C in SAVE_DATA may result in a tape with a parity error where it
was aborted.  To recover, one would have to erase the partially saved data by
spacing down the tape and writing and end-of-file mark in the proper place.  So
it would be best to avoid ending a SAVE_DATA abruptly. 

In general, jobs not required to be on Kronen should be run on Frankenheim.
SAVE_DATA can be run on Frankenheim instead of Kronen.  But in this case, the 
data must traverse the network (via Kronen) to get to Frankenheim and then back
again to get to the DAT tape.  So it is more efficient to run SAVE_DATA on
Kronen.  And the network traffic seems to run at a higher priority than the
SAVE_DATA job.  Lowering the SAVE_DATA on Frankenheim won't do much if
Frankenheim isn't busy. 

Finally, note that CLAS_OD will slow down if one allows the SPECTRA.SMT file to
get too big.  Changing priorities won't speed things up appreciably when this
happens.