MVSFORUMS.com

Vinodch · Posted: Thu Nov 29, 2007 8:54 pm Post subject: HIGH ELASPED TIME

We have a job one particular step runs for a long time -

CPU TIME 723.56
ELAPSED TIME 903.0

We checked the job not waiting for any files but still the difference between elasped time & CPU time is around 3 hrs; this particular step has lot of files used buffer parameters is this causing more elasped time please advice.
_________________
Thanks,
Vinod.

vivek1983 · Intermediate Joined: 20 Apr 2006 Posts: 222 Topics: 24

Vinodch,

Can you confirm whether there are any DB2 processing involved in the step?

dbzTHEdinosauer · Posted: Fri Nov 30, 2007 6:28 am Post subject:

i think you are forgetting the primary reason there is a difference between cpu and elapsed time.

cpu time is the total time that was allocated to this job by the system.

elapsed time is the wall clock time. usually the difference is due to other jobs also taking time slices.
_________________
Dick Brenholtz
American living in Varel, Germany

Vinodch · Posted: Fri Nov 30, 2007 8:51 am Post subject:

There are no DB2 tables involved only VSAM files used. In our shop the elasped time is billed to calculate the CPU hrs that's why I asked is there any way to reduce elasped time by removing unnecessary buffer index etc.
_________________
Thanks,
Vinod.

Bill Dennis · Posted: Fri Nov 30, 2007 9:01 am Post subject:

I agree with Dick. The job was using CPU 66% of the time which is quite good! Unless your job is the only one in the system you're not going to do much better.

Does your CPU time include both TCB and SRB? Is this a job that must complete within a certain batch window? Are there mutiple steps? The entire job stream would need to be examined for possible improvements.
_________________
Regards,
Bill Dennis

Disclaimer: My comments on this foorum are my own and do not represent the opinions or suggestions of any other person or business entity.

dbzTHEdinosauer · Posted: Fri Nov 30, 2007 11:57 am Post subject:

expat · Posted: Sat Dec 01, 2007 3:02 am Post subject:

A lot of it will come down to what you do qith each file, and of course how you do it.

One good tip - try to avoid using buffer allocations if using skip sequential processing.
_________________
If it's true that we are here to help others,
then what exactly are the others here for ?

Santlou · Posted: Wed Nov 12, 2008 8:20 pm Post subject:

Can you post the JCL for the step that takes the longest?
Also, have you tried running a Strobe or Omeagamon to see exactly what resources are used most heavily?
The standard tuning elements can apply. Like is the job doing a lot of Random VSAM keyed reads? Are the CI/CA sizes of the VSAM files optimum for your access? Are there any CA splits on the files? There are many things that you can look at to tune a batch job.
I suggest that you start looking at these elements and / or look at the source code that may be inefficient. If there are many sub program calls involved, depending on how they are called there may be too many BLDL's (I believe it's SVC 18??). But there can be many things that you can investigate.
Also, the job just may simply be doing a lot of CPU processing. The key to reducing elapsed time is to reduce the amount of physical I/O, thus reducing the number of time the system swaps the job out for other work.

Terry_Heinze · Posted: Thu Nov 13, 2008 12:01 am Post subject:

Vinod's last response was about a year ago -- I hope he/she hasn't been waiting for a solution all this time. Smile

_________________
....Terry

Santlou · Posted: Thu Nov 13, 2008 6:08 pm Post subject:

ah! my eye for detail isn't what it used to be! Shocked