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