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
