Current setting (0,0). As I said, z/OS 1.10. Level is about 0909, plus z10 buckets. I'll have to see about setting it back and "breaking it." Not my call in PROD and tough to simulate in the development LPAR, mostly because of the volatility of the input data.
As I mentioned in the original post, the assessment that (0,0) "fixed" the problem is the developer's read. I'm still skeptical for obvious reasons. I tend to think that any delays are more likely to be attributable to a disconnect between the way the DB2 tables are designed and the SQL calls. In the realm of my experience, that's a high percentage bet in most cases. But the developer and the DBAs have so far found no such issues. By "complex" I mean it accesses a number of DB2 tables and at least one VSAM file, some random, some sequential and sometimes quite a few table inserts. And it varies, again, according to volume, type and quality (how many error conditions are found). -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Mark Zelden Sent: Wednesday, October 13, 2010 3:55 PM To: [email protected] Subject: Re: Questions about CPENABLE On Wed, 13 Oct 2010 14:56:27 -0500, Miller, Pat <[email protected]> wrote: >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? > What was your prior CPENABLE setting (what is it set back to now)? 1) CPENABLE changes are almost impossible to measure outside a lab environment. I've always taken IBM's recommendations since they've done the work for me. 2) No, but you haven't said what your "other" CPENABLE setting is (unless I missed that). What is "a complex job"? Was that the only job affected? Can you change CPENABLE back to (10,30) again and "break it"? The last time I recall being able to measure a difference in a CPENABLE change was on 9672 G5 or G6 when it was set to something other than (0,0) (shared processors of course). Also, how old of an OS are you running and what is the maintenance level? I recall a problem with IRD and CPENABLE (IRD was config-ing off high order CPs), but that was at least 3 or 4 years ago. Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:[email protected] Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ ---------------------------------------------------------------------- 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
