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
