|
View previous topic :: View next topic
|
| Author |
Message |
saurabh39
Warnings : 1
Active User
.jpg)
Joined: 11 Apr 2008
Posts: 144
Location: Jamshedpur
|
|
|
|
Hi,
I have recieved a weird request. On friday, one of the program which runs for 2 hrs..took more than usual to run.
Client wants me to find the reason for the same.
Moreover, since it was taking time, they cancelled the job. And the record at the time of cancellation was put on bypass file. And somehow after that, the job run fine. They suspect, the record in bypass file as culprit.
But when, program was run with same record in test, the record was processed fine. There was nothing unusal about the data.
Now, I need some pointers as to how to start. But before that i need to find out, whether I can do something about the request.
So please tell me how to go about it? |
|
| Back to top |
|
 |
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8697
Location: Dubuque, Iowa, USA
|
|
|
|
| Contact your site support group and ask for their assistance. The elapsed time a job takes can vary depending upon time of day run, other jobs in the system, the service classes of each job in the system, the WLM (Workload Manager) rules used by the system, the number of initiators assigned, and on and on ... there are many, many, many possible reasons. Only someone working at your site can analyze the available data and determine which reason(s) applied to your particular job. |
|
| Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009
Posts: 2481
Location: Netherlands, Amstelveen
|
|
|
|
It is of course a manual tape mount or an operator reply not answered.
Its a known fact that operators are the weakest link in IT. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
| Quote: |
| Its a known fact that operators are the weakest link in IT. |
It is not a fact - just an opinion. . .
Many "operations" problems are caused by imcompetently/improperly implemented processes or documentation. Many are also caused by the necessity to manually change the job before each submission (again, part of the process that the operators did not define).
| Quote: |
| But when, program was run with same record in test, the record was processed fine. There was nothing unusal about the data. |
If the entire set of production data was not used for the test, the test was incomplete. . .
The problem may have been because of a combination of bad code combined with an unexpected combination of data elements causing the code to go into a loop.
How much cpu and i/o does the job usually take? How much cpu and i/o did the problem run take?
As was suggested, you should look for a missed console reply (there should not be console messages from an application unless it regards device allocation). |
|
| Back to top |
|
|
Kjeld
Active User
Joined: 15 Dec 2009
Posts: 365
Location: Denmark
|
|
|
|
| You could possibly get help from DBAs at your site to investigate if the row you have tried to access could have been subject to a lock issued by another process. That would explain that the row processed fine in test. |
|
| Back to top |
|
|
Anuj Dhawan
Superior Member
Joined: 22 Apr 2006
Posts: 6250
Location: Mumbai, India
|
|
|
|
| Looking at the JESMSGLG of canceled Job might help also. |
|
| Back to top |
|
|
Kjeld
Active User
Joined: 15 Dec 2009
Posts: 365
Location: Denmark
|
|
|
|
| PeterHolland wrote: |
It is of course a manual tape mount or an operator reply not answered.
Its a known fact that operators are the weakest link in IT. |
Many shops has eliminated these operator tasks completely, replaced manual tape mounts with tape robots or virtual tape storage and by minimizing/removing operator interaction with application programmes. |
|
| Back to top |
|
|
sushanth bobby
Senior Member
Joined: 29 Jul 2008
Posts: 1020
Location: India
|
|
|
|
Tushar,
Assuming this is a DB2 program,
In our place this sometimes happen during the month-end cycle, the daily DB2 batch programs runs few extra hours causing a bit of delay, when analyzed we found DB2 unaccounted Time be being high that was due to high CPU utilization and jobs waiting for CPU cycles.
Hope this helps,
Sushanth |
|
| Back to top |
|
|
|
|
