On Wed, 1 Sep 1999 11:13:07 -0400, "Jim Alton" <[log in to unmask]>
wrote:

>Before altering job priorities and queues may I suggest you spend a little
>time and attempt to identify the source of the performance bottleneck.

Excellent advice...

>If you determine your batch jobs simply aren't getting enough CPU, and you
>haven't access to Glance and it's Work Group process management
>capability... you might consider tuning your D queue to overlap the C queue
>and set the D queue to oscillate while the C queue decays.

More good advice...

>To illustrate... (I've forgotten the normal priority numbers)  If the C
>queue is currently set to priority range 150 - 200 and the D queue is set to
>range 210 - 250 a potential solution is to change the D queue range to
>175-250 and have it oscillate while the C queue decays.
>
>When a process is introduced to the C queue it will start at priority 150
>then work it's way down the scale to 200.  In decay mode, the process, if it
>runs long enough, will remain at priority 200.
>
>When a process is introduced to the D queue it would start at priority 175
>then work it's way down the scall to 250.  In oscillate mode, when the
>priority hits 250 it would then be reset to priority 175 and cycle it's way
>back down to 250.  This would continue until the process completed.
>
>Please beware, this may not be suitable for your environment and would
>negatively impact any online process of a lengthy duration.  The net effect
>should be... your batch processes will get more CPU, short online tasks will
>be unaffected, BUT... longer online tasks will now require more time to
>complete.

I have used this at many shops and have noticed no adverse effects to
online users.
>
>Another trick to consider... define the E queue to be a subset of the C
>queue priority range and place your 'special' jobs in the E queue.

This is a good one. Thank you.

<snip!>

Bob Tyler...