IIRC, Sysview will only have historical data if "History Datasets" (or whatever they are called) are allocated, which might or might not be your case. Anyway, it's worth a try!
------------------------------------------------------------------------------------------------------------------------------- *Lucas Rosalen* Emails: rosalen.lu...@gmail.com / *lrosa...@pl.ibm.com <lrosa...@br.ibm.com>* LinkedIn: http://br.linkedin.com/in/lrosalen Phone: +48 792 809 198 2015-11-20 15:39 GMT-02:00 Norman.Hollander <norman.hollan...@desertwiz.biz> : > 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 > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
