View previous topic :: View next topic
|
Author |
Message |
carolus
New User
Joined: 04 Jun 2007 Posts: 3 Location: Poland
|
|
|
|
Hi,
I'm running some strobe reports and in one case I have an high wait time (almost 90%).
Strobe associate this to the module IEAVEPS1:
Module Description Page Total
IEAVEPS1 POST SERVICE 0.00 84.03
I just wanted to ask if someone knows what this module is doing.
I was looking in internet and in IBM site, but i couldn't find any useful information.
I found a similar request last year in another forum (which i report down)
------- begin ---------
We are seeing some excessive wait times originating from
the modules
DSNAPRH
DSNXEEZ
Can anybody shed some light on what could cause DSNXEEZ / DSNAPRH
to wait for a very long time ?
When looking at a strobe report, the wait time is accounted to IEAVEPS1.
Anything in particular we should trace for ?
------ end -----
Even in that case it seems there was no answe
thanks in advance for your answer
carlo |
|
Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006 Posts: 6966 Location: porcelain throne
|
|
|
|
??? what is being executed? Unless someone has had experience with this particular module, we can only guess. The strobe report will give you a call chain. If you can not figure it out, at least share it with us if you expect an answer. |
|
Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006 Posts: 6966 Location: porcelain throne
|
|
|
|
IBM has an entry in the MVS diagnostics list
has to do with task management. Now, again......what is your run-unit doing? |
|
Back to top |
|
|
carolus
New User
Joined: 04 Jun 2007 Posts: 3 Location: Poland
|
|
|
|
The batch i'm monitoring is a normal (not so well designed ) batch.
It is doing high DB2 activity (select, insert & update) as well some Vsam access.
In my opinion we are loosing time because the query are not so well tuned, but i do not know if this is the real problem.
(sorry to answer late but i have limited access to net).
carlo |
|
Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006 Posts: 6966 Location: porcelain throne
|
|
|
|
carolus,
if the taskmanagment deals with DSN modules, then indeed you are waiting on DB2. The first thing to do when attempting to tune SQL is get an explain. If the bind parms are set-up for it (don't ask me, someone else will have to tell you) the explain can be generated at run time and is inserted into one the SYSIBM.tables... (again, I am not a DBA and I would have to search to give you the answer). your problems could range from simple- commits not made frequently
- commits made too frequently - doubt this is your problem
- convoluted multi-table joins
- multi-row subqueries to generate insert or update values
- too many table scans
and you need an explain to tell you this. And the explain output is complicated with RUNSTATS status.
But, you need to determine what is involved with the wait - i.e. what services are you waiting on. DB2, VSAM, etc....
Don't injure your credibility by assuming it is DB2. I have seen some multi-page convoluted sql that just screams, because it is properly tuned. |
|
Back to top |
|
|
carolus
New User
Joined: 04 Jun 2007 Posts: 3 Location: Poland
|
|
|
|
thanks for the answer.
I was already analyzing query by query, since the program rely strongly on DB2 and my idea is that in any cases the queries are not so well designed.
However i just needed to understand if checking the queries was making sense. Based on you answer i understood yes.
The environment where I'm working has automatic EXPLAIN whenever the program is compiled and hopefully there is a general RUNSTAT every week, so it is just a matter of time (something like 30 queries...).
again thanks for the answer |
|
Back to top |
|
|
|