Pat,

If you have CA-ASTEX it reports on IO Interrupt Delay.

If you have PAIO, perhaps you could run it at low IO rates at compare the
internal measured response time with RMF and try and correlate %TPI with the
difference.

Ron

> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:[email protected]] On
Behalf Of
> Miller, Pat
> Sent: Wednesday, October 13, 2010 12:56 PM
> To: [email protected]
> Subject: [IBM-MAIN] Questions about CPENABLE
> 
> We recently went to a z10-K02 BC. LPAR (3) mode.  No sysplex.  z/OS 1.10.
> Following IBM recommendations, we set CPENABLE(10,30) in IEAOPTxx.
> 
> Shortly thereafter, a complex batch job began experiencing lengthy elapsed
> times (3-5 times as long).  Realtime (CA-SYSVIEW) and postprocessor
analysis
> revealed no obvious reason for this.  CPU contention was not an issue. I/O
> response times and their subcomponents were virtually identical before and
> after the change.
> 
> To make a long story short, we backed out the change to IEAOPT (when all
else
> fails).  According to the developer, the job (which apparently accesses a
> number of DB2 tables in a variety of ways) has returned to normal elapsed
run
> times.  It's hard for me to judge, because the job runs numerous times
daily
> and varies substantially with the volume, type and accuracy of input.
> 
> I ran CPU activity reports for the same hours the days before and of the
> change.  Sure enough, TPI% was down, but hardly enough to make a
substantial
> difference in run times to my way of thinking:
> 
> HOUR          BEFORE          AFTER
> 09-10          4.94                    1.72
> 10-11          4.53                    0.92
> 11-12          3.24                    1.02
> 12-13          3.21                    0.96
> 13-14          5.78                    0.81
> 14-15          3.44                    0.99
> 15-16          3.79                    1.02
> 
> I guess I'm not convinced this should have made such a difference. I have
two
> questions:
> 
> 1. Is there any way to measure the time an interrupt waits for the FLIH to
> grab an enabled CPU?
> 
> 2. Does this make any sense to anyone else?
> 
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [email protected] with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Reply via email to