martin knott wrote:
> I had a probelm the other day in which none of my jobs (submitted in
> the D queue) were advancing at all. The users' sessions (in the C
> queue) didn't report any drop in perfromance at all. If a job was
> 'promoted' to the 'C' queue, it ran through ok.
>
> Does anyone have not-to-technical explanation of how the queues work
> together, and possibly an explanation for what was happening?

I looked ahead and nobody has touched on this one yet, so I'll take
my shot...

This can't be explained without a basic "reference", the best one
being the tail end of a :SHOWQ listing.  The default values are:

>                     ------QUANTUM-------
> QUEUE  BASE  LIMIT  MIN    MAX    ACTUAL  BOOST  TIMESLICE
> -----  ----  -----  ---    ---    ------  -----  ---------
>  CQ    152    200   1      2000   8       DECAY    200
>  DQ    202    238   2000   2000   2000    DECAY    200
>  EQ    240    253   2000   2000   2000    DECAY    200

Process scheduling is handled by the MPE Dispatcher.  Every process in
the system is classified (simplistically) into either "DORMANT" or
"RUNNING" columns in :SHOWQ output.  Dormant processes are those which
are waiting on something (terminal read, disc I/O, database lock, etc)
while those Running are ready to execute.  They may not all actually
be "running" - you can only be running as many processes at the same
time as you have processors.  But the remaining processes in the running
list are "eligible to run".

Processes that are running will continue to run until:

a)  They do something that makes them wait (issue a terminal read, or
    a disk I/O, etc), or
b)  They exceed their "quantum" of CPU time, in which case the
    dispatcher takes over and interrupts them.

The second case does not apply to system processes scheduled linearly
and some priv-mode exceptions, but let's keep this simple.

When the CPU is "available" through the conditions above, the dispatcher
must decide which process to launch next.  If there are no
processes in the running list, it simply suspends until some process
is ready to go.  Otherwise, the process with the lowest priority
number is selected.

Now, on to how the "numbers" are assigned.  From the :SHOWQ trailer
you can see that CQ covers 152-200, DQ 202-238, and EQ 240-253.  So,
in answer to your original question, as long as there is a process in
the CQ ready to run, nothing in the DQ will ever be selected as there
is no overlap.  One or more of your CQ processes must be CPU intensive
to dominate the CPU like that; generally there are "some" cycles
available to the lower queues.

What determines the numbers within the queues?  Processes start at the
base priority.  If they exceed their quantum before otherwise giving
up the CPU, their priority number is incremented.  This process
continues until it reaches the "limit" value.  Certain events can return
the priority to the base value - such as completion of a terminal read.
Hoever, if the process is compute bound, it may never rise back in
priority.  This is the default behavior of the "DECAY" algorithm.

An alternative to DECAY is OSCILLATE, which as the name implies, will
pop you back up to the base after you reach the limit.

Now, armed with this background, how do you solve your problem?  There
are probably a dozen or more different opinions depending on who you
ask, but in general:

* if the DQ is getting nothing, you must make it at least overlap the
  CQ by raising the DQ base above the CQ limit,

* if the DQ processes then get pushed below the CQ base and hang after
  they get started, you may need to raise the DQ limit or lower the CQ
  limit so that they have equal contention.

* If the DQ processes drop to the base and stay there, resulting in
  less than desirable performance from the DQ, you might consider
  changing the DQ to OSCILLATE.

This is just a simplified overview of the major players in process
scheduling.  It's a complicated issue when you get down to details,
so your mileage may vary.  Hopefully this will help you get started.

Jeff Kell <[log in to unmask]>