IBM Mainframe Forum

Hi,

One of our daily jobs is not taking CPU some days. Usually job takes 3 hours to complete.But sometimes a DB2 program in the job is not taking CPU and entire job takes more than 4 hours to complete which affects the entire job flow.
We have contacted performance team when the program not taking CPU and they were also not able to help much.
We can't start the job earlier or can't do any other schedule change.
Can anybody please suggest something to avoid the job delay ?

What's the WLM service class? How is that service class defined? What is the CPU utilization running? Did your performance team talk to the system programmers to find out what's holding up the job? The performance group would not be my first point of contact since you don't really have a performance issue but more of a non-performance issue.

Here is a terminology issue. "... is not taking CPU" is usually interpreted as not using any CPU time. I had to read through most of the post to realize what was really meant was, " ... not getting any CPU time." The trouble is this may not be the reality, either. All we know for sure here is something is happening that causes the job to take much longer than expected to run.

Many things can cause this to happen, Mr. Sample's analysis is incomplete.

The very first thing a performance analyst must do is examine the JESMSGLG datasets for a job that runs in the normally expected time and the job that required longer than expected.

The very first thing to check is the job start time. Did both jobs start when scheduled? A job that requires about three hours to run that starts an hour later than expected is going to end an hour late than expected. No performance analyst in the world can fix this problem!

Next, see if there is an environmental issue. Did the job have to wait for dataasets. This can be quickly determined in the JESMSGLG datasets? Does the job require manually mounted tape volumes? If it does, were the tapes mounted promptly? For that matter were there any other environmental issues, such as an allocation recovery?

Next, review the step times, both the elapsed time and the CPU utilization. A step that requires much more CPU time requires analysis. If there was more real work for the step, then that requires analysis, and is beyond anything we can do here.

All of these points are something you must do, and should do before you take the issue to the performance group.

Hello,

What you are seeing is possibly a job spending a lot of time waiting on "something".

As there is little cpu being used is there any i/o going on? Does this job use a database?

I belive if there's a DB2 step you'll not see CPU on the batch job, you'll see all the time being spent in the DB2 subsytem, you'll need to use a good DB2 monitor aslo to check for DB2 LOCKS, there could be a conflict between batch jobs or this batch job and online systems using the same DB2 table. , guys, correct me if I'm wrong about the CPU time, thanks

Hello,

If db2 query is (or has become) very inefficient due to data volume or content change, the process could be waiting on the return from the query. Poorly performing queries can take a long time for each iteration from the batch process making it appear that "nothing" is happening.

I don't know enough about db2 to say if any of the database cycles are shown in the application cpu usage or not. It has become accountable for chargeback, but i'm not sure about what might be seen in sdsf.