Page 1 of 1

Suggestion on a Looping job.

PostPosted: Thu Sep 15, 2011 7:19 pm
by Viswanathchandru
Dear all,
I have development system(LPAR) here wherein the jobs submitted by the developers/trainees gets into loop very often. Usually i use to find this through either the TGNUM value or through the EXCP Cnt. But today i found a genuine job( not a system or admin job) running with high TGNUM EXCP and also with considerable amount of CPU time . 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. I'm not sure whether this is the right place to post this topic. If not please transfer this to another topic. Apologies a ton if i'm wrong!!

Thanks,
Viswa

Re: Suggestion on a Looping job.

PostPosted: Thu Sep 15, 2011 7:57 pm
by enrico-sorichetti
You have no way of telling if a job is a legitimate user of systems resources or just a <hogger> ?

the best approach is to make intelligent use of the cpu parameter,
tweak things a bit so that these jobs can not fiddle with the cpu parameter
allow test jobs run only in certain classes with more stringent limits

Your effort of monitoring cpu utilization of running processes is certainly a nice toy,
but it will stay that ... a toy :D

apart the effort of reinventing the wheel ...

Re: Suggestion on a Looping job.

PostPosted: Thu Sep 15, 2011 8:03 pm
by Viswanathchandru
Thanks enrico, for your time and valuable reply as always...

the best approach is to make intelligent use of the cpu parameter


Is this through the manual monitoring. I'm not sure whether how to handle this.

apart the effort of reinventing the wheel

Nicely said!! since i'm just a newbie for this Legacy system ;)

Thanks,
Viswa

Re: Suggestion on a Looping job.

PostPosted: Thu Sep 15, 2011 8:28 pm
by enrico-sorichetti
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

Re: Suggestion on a Looping job.

PostPosted: Thu Sep 15, 2011 11:40 pm
by dick scherrer
Hello,

For what it is worth - when testing a new program or a newly modified program, the initial testing is best done with tiny amounts of data.

If a job is running and is getting all cpu or all i/o, it might be in a loop. If the job is getting both cpu and i/o, it can be very difficult to know if it is in a loop or merely has much to do. . .

Re: Suggestion on a Looping job.

PostPosted: Fri Sep 16, 2011 12:06 am
by steve-myers
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
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.

For printed output you have other options.

You don't really have any options for a general I/O loop other than monitoring, but these jobs will eventually time out.

Re: Suggestion on a Looping job.

PostPosted: Fri Sep 16, 2011 12:31 am
by Robert Sample
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.
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.

Re: Suggestion on a Looping job.

PostPosted: Mon Sep 19, 2011 6:25 pm
by Viswanathchandru
@Enrico: Thanks a lot for your time and valuable comments!
@Steve: thanks for your valuable comments and time!
@Robert: thanks for your valuable comments and time!
@scherrer: thanks a lot for your time and reply!


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.

thanks,
Viswa

Re: Suggestion on a Looping job.

PostPosted: Mon Sep 19, 2011 10:49 pm
by steve-myers
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. ...
1. All started tasks.
2. All TSO users.
3. All job classes. I'm not 100% sure what will happen mixing JOBCLASS(*) and JOBCLASS(v) as you propose, but I think it will work they way you think, provided JOBCLASS(v) is after the JOBCLASS(*).

Re: Suggestion on a Looping job.

PostPosted: Thu Sep 22, 2011 5:16 pm
by Viswanathchandru
Thanks a lot steve for your suggestions. Thanks all for addressing this post!!

Regards,
Viswa