the best approach is to make intelligent use of the cpu parameter
apart the effort of reinventing the wheel
Another option is to set a restrictive step time in the JES2 JOBCLASS (for a job class) statement. This does not require any action on the part of the programmer. See this link.enrico-sorichetti wrote:I just reread the topic..
I had a finger-check... I should have said time parameter.. on the job card
no monitoring at all..
define a default time parameter for test jobs, once the allotted CPU time has been consumed
the job will abend
There's no 100% accurate heuristic to tell you this -- it's mostly knowing your system and the peaks and valleys of system usage over time. Jobs that have high CPU usage without growing EXCP counts, for example, are usually -- but not always -- in a loop (it could just be a long-running CPU-bound job). As others have said, usually the first line of defense -- especially in a development / test environment -- is to set CPU limits (by job class or whatever makes sense) and use monitoring tools such as Omegamon or MainView to watch system performance.So, I got messed up with how to find whether a job is really running under loop. I really can't understand which factor decides that this job is screwing up the System.
1. All started tasks.Viswanathchandru wrote:... As suggested by you experts i have an idea of changing the JOBDEF in the JESPARM member. But i have a little confusion like in my shop i have three kinds of JOBDEF made.
1. JOBCLASS(STC) --> started task.
2. JOBCLASS(TSU) --> Logon task.( i believe apologize if i'm wrong)
3. JOBCLASS(*) ---> can't understand . does this means all the jobclass from (a-z)? if yes, can i define a new jobclass with name say JOBCLASS(v)? Apologize if i'm wrong. ...