Chuck- SysView definitely has historical reporting (has for many many years). As your SysProgs to show you how to access it. It is very easy to use.
-----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Hardee, Chuck Sent: Friday, November 20, 2015 6:13 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF/RMF Reporting question I have access and knowledge of SysView and SDSF. What our system programmers have I do not know. I'm thinking no, because their first attempt at giving me what I need was to use SysView. 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 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. -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Friday, November 20, 2015 8:51 AM To: IBM-MAIN@LISTSERV.UA.EDU 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
