I will have to look into this. Thanks! Charles (Chuck) Hardee Senior Systems Engineer/Database Administration EAS Information Technology
Thermo Fisher Scientific 300 Industry Drive | Pittsburgh, PA 15275 Phone +1 (724) 517-2633 | Mobile +1 (412) 877-2809 | FAX: +1 (412) 490-9230 [email protected] | www.thermofisher.com WORLDWIDE CONFIDENTIALITY NOTE: Dissemination, distribution or copying of this e-mail or the information herein by anyone other than the intended recipient, or an employee or agent of a system responsible for delivering the message to the intended recipient, is prohibited. If you are not the intended recipient, please inform the sender and delete all copies. -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Lizette Koehler Sent: Friday, November 20, 2015 9:00 AM To: [email protected] Subject: Re: SMF/RMF Reporting question And if you have not set this up, the RMF Spread Sheet Reporter might be helpful http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/TD106241 This recorded demonstration show how to install and setup the RMF Spreadsheet Reporter and how to run the IO Queueing report to obtain performance information related to Hyper PAV usage on the DS8000 http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.erbb 200/rpp.htm The RMFT Spreadsheet Reporter is the powerful workstation solution for graphical presentation of RMF Postprocessor data. Use it to convert your RMF data to spreadsheet format and generate representative charts for all performance relevant areas. The RMF Spreadsheet Reporter offers the following features: ease of use - manage the related resources by means of an Explorer-like GUI fast path to graphical presentation - prepare the SMF data in one single step batch mode - generate the input files for the spreadsheets without any GUI interaction AFAIK - No charge item, downloads RMF reports to the PC to run under a Java App Lizette > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of Lizette Koehler > Sent: Friday, November 20, 2015 6:51 AM > To: [email protected] > Subject: Re: SMF/RMF Reporting question > > Do you have any tools like SAS/MICS or SAS/MXG? > Any monitoring tools like Tivoli Omegamon, MainView? > > Lizette > > > > -----Original Message----- > > From: IBM Mainframe Discussion List [mailto:[email protected]] > > On Behalf Of Hardee, Chuck > > Sent: Friday, November 20, 2015 5:23 AM > > To: [email protected] > > Subject: SMF/RMF Reporting question > > > > Hello Everyone, > > > > I am trying to find, from a historical perspective, that is to say, > > after an > event has > > occurred, what units of work were using how much of the available CPU. > > Is there an SMF and/or RMF report that allows on to ask, > > > > "During the interval from hh:mm to hh:mm on a particular day, in > > increments of > y > > units, what was the consumption of CPU on a unit of work basis?" > > > > Another way to put it is, I am looking for a report that shows CPU > > consumption > in a > > context similar to the SDSF DA screen as one sits at their terminal > > and > presses the > > enter key. > > > > We are trying to find out who, during a specific interval of the day, > > was > consuming > > the greatest amount of CPU to the ultimate effect that it essentially > > stopped > one of > > our database regions from executing and thereby causing it to think > > some of > its > > subtasks had gone into a runaway CPU condition so it aborted them as a > preemptive > > action against bad coding. We know that the code is good, it's been > > literally > running > > for years with no changes and, until the last couple of weeks, has had > > not a > single > > hiccup. Over the last couple of weeks, for no reason we can identify > > as of > yet, the > > code has randomly been aborted by the database software in which it > > runs, as a runaway task. > > > > The theory is that the runaway check process is actually reporting a > > false > condition > > since it is based on wall clock time (this is vendor code, not ours > > and I'm > not going to > > debate it one way or another). What the vendor theorizes is that > > another task > in the > > system, yet to be identified, has stolen the CPU away from the > > database and > held on > > to it long enough such that when the database finally regained access > > to the > CPU, > > the runaway interval had been exceeded by the internal task executing > > our code > so it > > was aborted for a potential loop within the code. > > > > The database vendor has suggested looking for this kind of information > > in > order to > > confirm or deny that the database had the CPU it needed or if another > > task > within > > the LPAR had control. If we find that the database had the CPU, then > > the > vendor has > > more analysis work to do on the dump with a more powerful magnifying > > glass, or > we > > have to turn our sights on someone else, either ourselves or, > > possibly, > another > > vendor for another product. > > > > Thanks for any thoughts you may have on this. > > Chuck > > > > > > Charles (Chuck) Hardee<mailto:[email protected]> > > Senior Systems Engineer/Database Administration EAS Information > > Technology > > > > Thermo Fisher Scientific > > 300 Industry Drive | Pittsburgh, PA 15275 Phone +1 (724) 517-2633 | > > Mobile +1 > (412) > > 877-2809 | FAX: +1 (412) 490-9230 > > [email protected]<mailto:[email protected]> | > > www.thermofisher.com > > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
