Hal, OK, the OP is believing how RMF III reports DASD Delays (not contention). Let's stop at that basic error.
Connect time is counted as "Using" in RMF III, so opportunities to reduce IO elapsed time by reducing IO count, as you described, will never be found with RMF III delay analysis unless there is some substantial Disconnect or Pending Time associated with the total IO count. You have to look at the USING value as well, and with current Disk subsystems I would suggest eliminating that as the potential tuning opportunity (technically or politically) before moving to the RMF III delay metrics. Remember RMF III still thinks we have real 3990s. Ron > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of > Hal Merritt > Sent: Tuesday, July 27, 2010 8:14 AM > To: IBM-MAIN@bama.ua.edu > Subject: Re: [IBM-MAIN] Any ROT for DASD Response time > > See imbedded. > > Hal > > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of > Ron Hawkins > Sent: Thursday, July 22, 2010 10:54 PM > To: IBM-MAIN@bama.ua.edu > Subject: Re: Any ROT for DASD Response time > > Hal, > > I should have been clear. The statement I disagreed with is: > > " It does not really matter what the response times are, > the issue is that they are too slow" > > I'm not sure where I can agree with you, and I still fail to see how near > perfect response time can be too slow. > > >>> If the DASD is delivering near perfect response times, then it can't go > faster. If that's still not fast enough, then one -must- address I/O > reduction. War story: most loved online was hitting a ceiling and just > wouldn't scale past a specific transaction load. The cause was traced to a > single checkpoint dataset. The fastest hardware available was brought in but > it was not fast enough. The very reluctant, politically powerful support team > was forced to address the I/O to that dataset. A relatively minor change > solved the problem. The point is that making application changes may meet with > a -lot- of resistance, but ya gotta do whatcha gotta do. To be fair, -any- > change to that application was a medium to high risk. > >>> > > Any volume averaging 0.3ms response time is pretty close to zero delay, where > a delay is something queued or waiting. I'm not sure why you don't believe > this. > > >>> The OP reported measurable delays. Therefore, it was unlikely the DASD was > delivering optimal response times. > >>> > > ..snip > > I believe Response time does matter because it is a guide to the action > required. It just should not be considered as the only metric that decides if > IO is delaying an application. > > >>> That's the key point putting us into substantial agreement. > >>> > > > ..snip > > Ron > > > > > > -----Original Message----- > > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf > Of > > Hal Merritt > > Sent: Thursday, July 22, 2010 7:49 AM > > To: IBM-MAIN@bama.ua.edu > > Subject: Re: [IBM-MAIN] Any ROT for DASD Response time > > > > Short answer: yes. And you go on to agree. Let's take a look at the OP's > > issue: Not meeting SLA's. A logical first place to look is DASD, and we find > > 'delays'. What kind of delay and how long of a delay we don't know. > > > > The question is how long of a delay is normal and to be expected. A ROT for > an > > acceptable range. I find it a little hard to believe that a DASD subsystem > can > > deliver 0.3ms response times with measurable delays. Therefore, IMHO, any > > measurable delay should be investigated and, if feasible, reduced. To zero. > > > > Of course, I/O avoidance is almost always something we want to consider. But > > that does not address the OP's question. > > > > > > NOTICE: This electronic mail message and any files transmitted with it are > intended > exclusively for the individual or entity to which it is addressed. The > message, > together with any attachment, may contain confidential and/or privileged > information. > Any unauthorized review, use, printing, saving, copying, disclosure or > distribution > is strictly prohibited. If you have received this message in error, please > immediately advise the sender by reply email and delete all copies. > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
