Your pools probably look something like this:
System Pool Reserved Max
Pool Size (M) Size (M) Active Pool
1 547.09 269.22 +++++ *MACHINE
2 3060.53 7.86 258 *BASE
3 783.90 .00 96 *INTERACT
4 3271.25 .14 52 *SHRPOOL1
5 15.34 .00 6 *SPOOL
Obviously your actual numbers are different, but the key is this: You
need enough memory and activity level in the pool your subsystem is
using to run the workload you want to run.
This system may or may not have a shared pool, but most likely you do
not want to run a batch job in your interactive subsystem because the
priority of the interactive jobs will mean that your batch job gets
serviced last. This may also be what is happening in QPGMR.
Try doing a WRKSHRPOOL and F11, and see what the minimum Size % is for
the pool the job is running in (probably *BASE or *SHRPOOL1) Try
setting the minimum to a "reasonable" number for this system; if you
have a small amount of memory a "reasonable" number might be as high as
50%. This will keep the performance adjuster from robbing the batch
pool for your interactive pool.
Then do a WRKACTJOB SBS(QPGMR) and F11. This will show you the priority
level of the other jobs competing directly with your slow job. Make
sure that your slow job is running at (at least) the same priority as
the other jobs in QPGMR. If it is not you'll need to check the routing
entries and job class.
Question: Was there a recent change or has this job always ran in this
subsystem? Perhaps someone made a change to another job in the SBS
(priority?) causing that job to steal resources from this one.
Regards,
Scott Ingvaldson
Senior IBM Support Specialist
-----Original Message-----
From: James H. H. Lampert [mailto:jamesl@xxxxxxxxxxxxxxxxx]
Sent: Wednesday, December 15, 2010 10:49 AM
To: Midrange Systems Technical Discussion
Subject: Re: Can the subsystem a job is running in make it run slowly?
The latest:
The customer got back to us on the idea of trying a different subsystem:
The reason why we don't want it in QINTER is that we don't want it
taking up interactive resources from our nightly operations as our
China offices are . . . <censored; would reveal too much about who
the customer is>.
My answer to that was to the general effect that:
The fact remains that it is running in a subsystem that appears to be
starved for resources (and given what normally runs in that
subsystem, probably intentionally so . . . ).
It is taking hours when it should be taking minutes. At present, the
subsystem it's running in is the prime suspect for that. Running a
single test in another subsystem is not the same thing as permanently
moving it into that subsystem.
Further suggestions on how to test the "subsystem is the cause"
hypothesis would be appreciated.
--
JHHL
midrange.com
