RE: best way to limit a job

I am trying to assuage a client's dissatisfaction that a particular job is
consuming the most CPU of all concurrent tasks. He feels it is keeping
other tasks from completing faster, or responding quicker. I've already
tried to explain that if the system has resources to give, why not let it
use it? If the task were not running the total CPU% would go down but other
tasks would not necessarily complete quicker. The task already has a run
priority of 75, lower than anything else they are running, so this task
should get paged out or delayed in some way if another higher priority task
needs the resources.

So, if I can simply limit the task to a ceiling of x%, I'm thinking that
might satisfy him.


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Lindstrom, Scott R.
Sent: Wednesday, May 16, 2012 1:37 PM
To: Midrange Systems Technical Discussion
Subject: RE: best way to limit a job

When I moved to the AS/400 years ago (from IBM mainframe) one of the first
things I was taught was not to think the same way about CPU %. If the
machine has it available why not let a job have 100%? As long as the mix of
jobs are playing well together (job priority, memory, etc) it's best to let
each job take as much as it can.

Or am I misunderstanding what you're trying to accomplish?

Scott Lindstrom


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Thomas Garvey
Sent: Wednesday, May 16, 2012 1:10 PM
To: 'Midrange Systems Technical Discussion'
Subject: best way to limit a job

I'm looking for the best and simplest way to limit how much of the system a
particular job will take. Ideally, we would be able to configure a job so
that it won't take more than x% of the CPU (as seen on a WRKACTJOB display).
We've tried using *CLS objects, defining Run Priority and Time slice
seconds, but it doesn't seem to limit the job. It still takes as much of
the CPU as it wants.

Suggestions?

Tom Garvey

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe,
or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe,
or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l.