Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ucbvax!YALE.ARPA!LEICHTER-JERRY
From: LEICHTER-JERRY@YALE.ARPA.UUCP
Newsgroups: comp.os.vms
Subject: Re: process priority levels
Message-ID: <8706200338.AA07400@ucbvax.Berkeley.EDU>
Date: Fri, 19-Jun-87 23:39:02 EDT
Article-I.D.: ucbvax.8706200338.AA07400
Posted: Fri Jun 19 23:39:02 1987
Date-Received: Sun, 21-Jun-87 00:44:38 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: <LEICHTER-JERRY@YALE.ARPA>
Distribution: world
Organization: The ARPA Internet
Lines: 53


    ...

    1) Will VMS schedule jobs at two priority levels "fairly" or will the
    lower priority jobs never get reasonable response? ...

This isn't easy to answer.  Down at the bottom of it all, at any given moment,
the runnable process with the highest priority will be run.  So in this sense,
the answer is no.  However, there are two (well, three - more below) priori-
ties associated with a job:  Its base priority, and its current priority.
When you set the priority of a process, you are (mainly) manipulating its
base priority, which is the lowest the current priority will ever go.  How-
ever, all but CPU-bound jobs spend most of their time above their base prio-
rity, since various events like I/O completion gain the process a boost.

In principle, a priority 3 CPU-bound job will get no CPU time on any system
with a fair number of users.  In practice, unless the system is very heavily
loaded, you'll tend to see short periods of time when, but chance, a couple
of people are doing compilations (say) when the priority 3 job will be locked
out, but you'll also see long intervals where the priority 3 job chugs away
nicely.  You can get a quick picture of how well those jobs will do by using
MONITOR - any CPU time the priority 3 jobs manage to take from the system will
come mainly from the NULL job.  (That's not quite true, since a priority 3 job
with a priority boost of 3 for an I/O completion will take time from any prio-
rity 4 CPU bound job.)

Just to make life a little more complex, VMS has a special facility, control-
led by the PIXSCAN parameter in SYSGEN, which gives computable processes a
special boost every once in a while.  This mechanism is there to guarantee
that even low priority, CPU-bound processes don't stall indefinately.  (The
problem with allowing them to is that they may be holding a lock on some
resource, like a file, and thus stalling high-priority processes.)
    
    2) Is their a way to set a process priority limit downward such that
    the user can't set it back? The documentation for SET PROCESS/PRIORITY
    and SYS$SETPRI seem to be misleading....

Prior to VMS V4, you could not (without ALTPRI) raise your process priority.
In V4, processes gained a third priority field, the authorized base priority.
You can now lower your priority, or raise it no higher than your authorized
base priority (which is also the base priority LOGINOUT sets for you to begin
with).

Note that a base priority specified for a batch queue overrides any authorized
base priority - you can't SUBMIT a job to a low-priority queue, then raise its
priority to interactive level, either from within the batch job or from an
interactive job.

Either you are looking at old documentation, or there is new documentation out
there that could use some fixup.  Documentation SPR time?

							-- Jerry
-------