ERBRMFPP Comes free.
See the RMF USER'S GUIDE - -teD - Original Message From: Lizette Koehler Sent: Friday, November 20, 2015 08:50 To: IBM-MAIN@LISTSERV.UA.EDU Reply To: IBM Mainframe Discussion List 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:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Hardee, Chuck > Sent: Friday, November 20, 2015 5:23 AM > To: IBM-MAIN@LISTSERV.UA.EDU > 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:chuck.har...@thermofisher.com> > 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 > chuck.har...@thermofisher.com<mailto:chuck.har...@thermofisher.com> | > 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. > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
