Lee,

I have seen this frequently.  As I understand it, if a process in the DS
queue is holding a resource that is needed by a process in the CS queue,
the dispatcher will bump up the former so that it can release its
resource.  I assume that the DS process promptly says "hey, I have a
slice of time, let's party."

We use KLA (or whatever Unison calls it now) to control things like
SUPRTOOL, rather than altering their priority.  Our thinking is: let the
programmer have enough of a shot in the CS queue to parse and syntax
check the code (we do everything in USE files).  If the process is going
to read 1 million records, sort, etc., the programmer will shortly be in
the ES queue and a little after that come along sheepishly to ask that
we abort his/her session.

Leonard Berkowitz



______________________________ Reply Separator _________________________________
Subject: Performance question (CS session running DS process)
Author:  [log in to unmask] at Internet-Exchange
Date:    10/22/96 10:03 AM


Dear listers:

I'm seeing a situation on our 992-400 recently which has me puzzled,
and I'm probably forgetting something very basic to explaining this
problem; therefore, I'm seeking expert advice ...

occasionally, a programmer will execute a SUPRTOOL extract from a
session, and the process will launch in the DS queue because we've
specified a maxpri=DS for SUPRTOOL via the Link Editor.  The process
extracts data from a database also heavily accessed by our major online
application, and the SUPRTOOL extract generates what I would consider
heavy disk I/O - roughly 10K-12K in a 5-minute interval - and 10-12%
CPU consumption.  Meanwhile, we'll watch as CS user processes
occasionally begin to back up behind widening queues on the disks which
hold these datasets, and response times go into the toilet.

The question boils down to:  is it possible for a DS-queue process to
preempt a CS-queue process for disk I/O?  The extract in question is
writing to a flat file on the same disk volume set, but it's opened the
database for read-only access.

TIA,

Lee Gunter          [log in to unmask]
HMO Oregon