RE: Job run times occasionally seriously spike. How do I start to figure this out?

["Steinmetz, Paul" <PSteinmetz@xxxxxxxxxx>]

Rob,

Any change any idx builds occurring.
They can have a huge impact.
Check these jobs.

QDBSRV04       QSYS        SYS      .0                   DEQW
QDBSRV05       QSYS        SYS      .0                   DEQW

Paul

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Rob Berendt
Sent: Tuesday, November 22, 2016 9:21 AM
To: Midrange Systems Technical Discussion
Subject: RE: Job run times occasionally seriously spike. How do I start to figure this out?

Thanks.


Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail to:  2505 Dekko Drive
          Garrett, IN 46738
Ship to:  Dock 108
          6928N 400E
          Kendallville, IN 46755
http://www.dekko.com





From:   "D*B" <dieter.bender@xxxxxxxxxxxx>
To:     "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
Date:   11/22/2016 09:11 AM
Subject:        RE: Job run times occasionally seriously spike. How do  I 
start to        figure this out?
Sent by:        "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>



<Rob>
Yes the tables are journaled. However the count of journal entries are
identical (or pretty darn close).
In the joblog the longest period of time is eaten up by this program:
CALL PGM(ERPLXPTFO/CST600B)
CST600B SQLRPGLE CST600B-Load Std Costs from Routings
Based on the day the runtime of this program varies widely.
</Rob>

... as I mentioned before, I/O% doesn't vary. so runtime seems to be 
related 
to I/O work. journals give a picture of the write operations. For the 
RPGLE 
programms DB-Monitor would be the tool of choice.
If you don't want to start DBMON in the night time, you could start it 
time 
scheduled (be sure, that you've enough dasd available) - choose the 
details. 
Before analyzing the data with oops nerv, you should delete the data of 
the 
other jobs, so it is easier. First I would have a look to are the most 
expensive statements and the overall count of database operations. Now you 

could have an estimate what the programm is doing half of time (other half 

is cpu).

Next step would be waiting for along run and compare.

You must first get an idea why the programm takes the time it is taking 
and 
what it's doing.

D*B