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
