Clint Schwartz writes:
>  1.  We changed our "queues" so that the job "queue" and the session "queue"
>did not overlap because of some known problem with sessions that wait on
>message files.  Evidently if a session drops down to the bottom of its
>"queue," it doesn't get bumped back up to the top of its queue like 4.0 did.
 
In dealing with a similar problem, our interrim solution was to shorten the
CS queue and set it to "oscillate", making the scheduling algorithm more
round-robin than priority queue. This prevented a lot of short transactions
from monopolizing the CPU at the expense of those processes that should
have been bumped up but weren't any longer.
 
   TUNE;CQ=152,160,100,1000,oscillate
 
Of course if you DO have a real CPU hog in the queue, it'll get a lot more
of the CPU than it would with the default parameters. But then you
shouldn't be running CPU hogs in the C queue in any case.
 
Our final solution was to make the application run faster, but you may not
have that option :-).
 
-- Bruce
 
---------------------------------------------------------------------------
Bruce Toback    Tel: (602) 996-8601| My candle burns at both ends;
OPT, Inc.            (800) 858-4507| It will not last the night;
11801 N. Tatum Blvd. Ste. 142      | But ah, my foes, and oh, my friends -
Phoenix AZ 85028                   | It gives a lovely light.
[log in to unmask]                 |     -- Edna St. Vincent Millay