<<The queues on our 957 running approx 50 sessions and a handful of batch
processes is as follows.  In general we use CQ for true OLTP
applications, DQ for batch jobs and EQ for online users with cpu hungry
applications. (Mainly to protect our CQ users)

We are increasing the number of hungry users all of the time and I have
noticed that in some circumstances STORE type operations will grind to a
complete halt with our current set up.

I need a compromise solution that will enable my online users to get
sensible response times from their online reports but at the same time
protects my high volume, low CPU OLTP users and my background operations
type tasks (stores and the like).>>


I definitely second the suggestions from Jim et. al. about overlapping
the queues. Here's what we use:

QUEUE  BASE  LIMIT  MIN    MAX    ACTUAL  BOOST  TIMESLICE
 -----  ----  -----  ---    ---    ------  -----  ---------
 CQ    152    200   1      2000   4       DECAY    200
 DQ    196    238   2000   2000   2000    DECAY    200
 EQ    234    255   2000   2000   2000    DECAY    200

50-60 interactive users shouldn't be that much of a load on a 957, unless
it's constrained by memory.

Also, I'd recommend running your CPU-starved STORE jobs in DQ, or even
CQ. STORE is I/O bound, so it isn't going to use tons of CPU time (though
it will require more if you're using TurboSTORE with software
compression; that might point toward DQ over CQ), and running it in a
higher queue will allow it to compete for the CPU time that it does need.

Steve