Steve,

Generally speaking, if batch performance degrades it is typically because
interactive demand has increased.  If you attempt to push batch jobs into
the interactive queue, two things will happen.  First, batch performance
will probably improve.  Second, interactive performance will degrade.  Is
this really what you want?

Someone else mentioned that you should take some pains right now to figure
out why performance has degraded.  I completely agree.  Your performance
problems may be I/O- or memory-related rather than CPU-related.  Maybe your
databases are impeding throughput.  Maybe you are experiencing disk
contention/fragmentation.

Again, generally speaking, it is not good to either put batch jobs into
interactive queues or alter the C and/or D queues settings.  I definitely
don't agree with altering the JOBPRI setting for the DQ.  I would much
rather see you, if absolutely necessary, alter the E queue so that it
occupies the lowest reaches of the C queue (198-200).  This way you can be
very specific about what jobs you put in there without allowing, carte
blanche, most/all jobs in the D queue to compete with some/all interactive
sessions.

Also, depending on your application, you may not be able to accomplish what
you are suggesting you want to do with the queues anyway.  For example, if
your application is Powerhouse most of the interactive sessions will spend
most of their time at priority 152.  Overlapping queues or putting batch
jobs directly into the C queue won't have the desired impact.

One comment was made that best performance comes through running a single
batch job.  That is sometimes true (and it may be true in your situation)
but is an oversimplification in most cases.  Actually, in a multi-processor
environment it is far better to increase the parallelism of the batch
processing than it is to continue to run the processing in a serial fashion.

Lastly, although the priority of a process is a very important
consideration, it isn't the only consideration affecting overall
performance.  For example, the MPE memory manager isn't very smart when it
comes to process priorities.  It is possible (and likely) to have
interactive processes have their throughput impeded by batch processes
because of the much heavier memory demand placed on the system by batch
processes.  This has led me, and most other MPE performance people I know,
to recommend that people leave the queues at the defaults and address
throughput issues other ways.

Good luck.

Bill Lancaster

At 09:49 AM 9/1/99 -0500, Steve Hammond wrote:
>I am running a 987 with over a gig of memory.
>
>I have some users who have lately seen a degradation of performance on
jobs running during the day. They would like their jobs to run in the C queue.
>
>I know I can put ";pri=CS" in their job card, but I can't remember if
there is anythig else I need to do to allow jobs to run in the C queue.
>
>Also is there anything different I can do to allow the jobs to run in the
C queue, in particular, anything like th TUNE command that targets specific
jobs and moves them to the C queu when they start up?
>
>thx
>steve hammond
>aamc
>wash dc
>
>