On 07/04/2018 06:46 AM, Peter Hunkeler wrote:
>> But if you specify the desired time on the job statement (the OP said 30
> min?), IEFUTL would get called and could take the desired action (extend for
> another 30 after generating some console message?).
>
>
>
>
> I stand corrected. I had in mind he wanted an alert when some address space
> consumes more that a certain amount of CPU *percent*in an interval, not time.
>
>
> --
> Peter Hunkeler
>
>
>
>
I think the original poster really needs to consider what his objective
is. By itself, percentage of CPU used in real time is not a reliable
indicator of a problem with a job. A perfectly tuned complex job on a
lightly loaded system may consume a high percentage of a physical CPU
for an extended time, but this is goodness if it completes in that much
less real time and it shouldn't be penalized for being well-tuned. A
job in an infinite loop on a heavily-loaded system may not show up with
as high of CPU utilization, but can soak up enough remaing CPU resource
to raise your 4-hour MSU average and either raise software charges or
result in LPAR capping which could then cause performance issues.
The least expensive solution is to set "reasonable" (for your
installation) default CPU TIME limits on job classes and in cases where
the default TIME is inadequate use reasonable TIME limits on JOB and/or
EXEC cards to catch job steps that are using much more total CPU time
than is expected. You can write your IEFUTL exit to be sensitive to
production job classes and allow the Operator to choose to extend the
CPU time for production jobs that appear to be doing useful work, unless
the total time is completely out of line with historical usage by the
job step.
Joel C Ewing
--
Joel C. Ewing,Bentonville, AR jcew...@acm.org
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
