Re: Why not *SHRPOOL1?

["Steve Landess" <steve_landess@xxxxxxxxxxx>]

> Rob wrote:
> I thought that time slice was a function of the class/routing
> entry/subsystem description and not the WRKSHRPOOL.
> Therefore if you had interactive, and batch, jobs running in the same
> shared pool they would still have different time slices based on their
> origination.  Wouldn't they?

Yes.  You are right.

If you have different subsystems sharing a memory pool, the jobs running
within the shared memory pool can have different time slice/run priority,
based on the class that was used to start a given job.  Interactive jobs
typically use a short time slice with a low run priority {say
timeslice(500), runpty(20)}, and batch jobs typically use a longer time
slice with a higher run priority {say timeslice(5000), runpty(50)}.

Based on this fact, the point I was trying to make is that it is not a good
practice to have batch jobs _and_ interactive jobs running in the same
memory pool.  You need to balance the working being performed in a given
memory pool to have jobs that are alike in timeslice/run priority running in
that pool.  This helps prevent system thrashing.

This goes back to the early days of performance tuning on the S/38...I'm
sure that if you read more about this in the Work Management Guide, you'll
see what I am talking about.  As a matter of fact, I'll go look there and
see if I can't find a reference to forward to you.

Al - please correct me if I am wrong...

Steve Landess
Austin, Texas
(512) 423-0935