Rex, The meaning of Time is explained quite nicely at http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ERBZRA91/5.1.3?SH ELF=ERBZBK91&DT=20091215152130. If you're having a problem reading the fine manual, it says "The time the interval began, where hh is hours, mm is the minutes, and ss is seconds."
I think you have answered the other questions for your self - the 30 minute interval. Omegamon and RMF get their data from the same source, RMF, so the only difference is that with Omega on real time displays the values you are looking at are more like RMF Monitor II with Delta on, than the average of response time over 30 minutes. The symptoms you describe are exactly what one would expect to see from classic Sibling Pend. The IO activity for the resynch is hosing your MF sequential Pre-fetch. You may have already had a problem before the Open System Cloning started running, and this has tipped it over the edge. Time for some classic disk tuning activity. Ron > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of > Pommier, Rex R. > Sent: Friday, August 13, 2010 2:36 PM > To: IBM-MAIN@bama.ua.edu > Subject: [IBM-MAIN] RMF and disk activity questions > > Hello list, > > I have a couple questions, one general question on RMF reporting and the other > on a specific DASD problem I'm having. > > First the general question. On the monitor 1 post processing reports, what > exactly does the "TIME" field represent? I know this may sound like a silly > question, but here's where I'm coming from. If I have RMF set to sync with > SMF at a 15 minute interval, RMF cuts records at the end of the 15 minute > interval for the preceding 15 minutes and passes this record to SMF for > safekeeping. Along comes the post processor, which I will run for a 2 hour > interval, RTOD(1400,1600) for example. The first interval report from the > post processor shows a TIME field of 14.00.00. Does this report segment > represent the 15 minute interval beginning at 14:00 or the one ending at 14:00 > (ie, when the RMF record was cut and handed off to SMF)? > > The preceding question came about because I'm trying to diagnose a problem > that we're having with our disk array performing cloning on the non-mainframe > side of the array that is killing performance. I'm seeing wildly different > pictures coming out of Omegamon and RMF. Here's the scenario. The Oracle > DBA kicks off a clone of a database that is sitting on the same physical > spindles as my Z data. At the same time I'm running a DFDSS job that dumps 40 > or so 3390 mod 9 volumes to 3592 tape. Under normal conditions (without the > Oracle junk happening), this dump job runs in about 2 hours, with each volume > taking 2-4 minutes on average. When the cloning is taking place, the volume > dumps are taking 15-20 minutes per volume. Watching Omegamon, it is recording > 200-250 millisecond response times on the disk volume being backed up, with > most of that time being spent in DISCONNECT. Our disk vendor is aware of this > and is attempting to figure out how to fix it. The problem I'm ha! > ving is that RMF monitor 1 DASD reports is showing average response times in > the 5-10 millisecond range and I'm not seeing these huge response times that > Omegamon is showing. Caveat, during this time frame, RMF was recording at 30 > minute intervals. > > Can somebody explain why I would be seeing good response times in RMF, even > though Omegamon and the clock are both showing that the disk response time is > in the tank? I would have thought that even with the 30 minute interval, the > fact that a backup was running on the affected volume for 15 minutes of that > interval, with nothing else running on the volume while it wasn't getting > backed up, it would show poor response times. > > Thanks. > > Rex > > The information contained in this e-mail may contain confidential and/or > privileged information and is intended for the sole use of the intended > recipient. If you are not the intended recipient, you are hereby notified that > any unauthorized use, disclosure, distribution or copying of this > communication is strictly prohibited. If you received this e-mail in error, > please reply to sender and destroy or delete the message and any attachments. > Thank you. > > ---------------------------------------------------------------------- > 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
