Automatic process to identify jobs that went to loop

k_rajen1 · New User Joined: 03 Jun 2009 Posts: 13 Location: Hyderabd

Hello,

I would like to know if there is any automatic process to identify jobs that went to loop during runtime.

As per my understanding if Expection count is not increasing and CPU % is increasing then the job would be in loop, now i want to know is there any process which can identify this one with out user mointring.

Regards,
Rajendra K.

enrico-sorichetti · Posted: Fri Jun 26, 2009 1:26 pm

NO...
the CPU consumption depends on the application/program <work to do>

the TIME parameter is there exactly to avoid that
at testing time You would discover approximately the resource need,
maybe after a couple of abends

and when creating the production jcl You would be able to to use the proper TIME parameter

k_rajen1 · New User Joined: 03 Jun 2009 Posts: 13 Location: Hyderabd

enrico,

Thanks for infroamtion provided.

But my issue is if there is a job which runs for long time, we need to use a maximum time parameter, in this scenario how can we identify if the job went that went into loop.

enrico-sorichetti · Posted: Fri Jun 26, 2009 2:08 pm

proper testing

Robert Sample · Posted: Fri Jun 26, 2009 4:57 pm

One rule of thumb: if you give the job more time, and it still has the S322 abend, there may program looping involved.

That said, there is no absolute standard for this. One job may require 60 minutes of CPU time to do the work while another needs 10 seconds. Is the first one looping just because it uses 360 times the CPU? No, it just has more work to do. Experienced programmers have a rough feel for how much time the job should run, but they are not always accurate.

If your site is licensed to use one of the run time analyzers, running it on a program suspected of looping will help you identify where the program is spending its time.

dick scherrer · Posted: Fri Jun 26, 2009 9:01 pm

Hello,

A job that does not abend with a time out may still in fact be looping - just not fatally. . . For example, some loop always processes all 10,000 entries in an array even though it could/should have quit the loop on the first "hit".

The easy ones to spot are the ones that abend. . . The ones that simply waste tremendous amounts of system resource may take a bit of work to identify.