Re: SMF/RMF Reporting question

[Scott Chapman]

As others have said, there are multiple ways to go look at what was using the 
CPU during a particular interval, depending on what tools you have access to 
and what the system configuration is. To recap:

SMF 30 interval (subtype 2 & 3) records will show CPU utilization by interval 
by address space.
SMF/RMF 72 subtype 3 records will have utilization by service class and report 
class. Depending on how WLM is configured the report classes may be fairly 
granular or may be almost non-existant. 
RMF III's PROCU panel can be very handy for looking at processor utilization on 
a more granular timeframe in the recent past. (Assuming it is so configured.)
Other system monitors such as SysView (which I know nothing of) or Omegamon 
usually have history recording capabilities that can be leveraged.

However, I would submit that perhaps the more interesting question in this case 
is: "was the service class that the affected work was running in significantly 
delayed for some reason?" RMF III will again give you some insight into this 
via the DELAY panel. You have to be a little careful with that as there's no 
clear indication of the number of samples. (Although this tends to be a bigger 
issue on the enclave panel, because some enclaves tend to come and go rather 
quickly.)

From an SMF perspective, the 72.3 records include details about the delay 
samples on a service class / report class basis. 

Finally, you mention that you know the code is good because it hasn't changed. 
But remember that the data may have changed over time; in particular the data 
volume may have changed. I have seen instances where the volume grew to a point 
that performance changed noticeably and relatively suddenly--because an extra 
level was added to an index or the data had grown disorganized or large enough 
that it crossed some threshold and the database optimizer started using a 
different access path. I'm not saying this is the case here, I just mention it 
as something to keep in mind. 

Scott

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SMF/RMF Reporting question

[Bob Rutledge]

IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> wrote on 
11/20/2015 07:22:44 AM:

> From: "Hardee, Chuck" <chuck.har...@thermofisher.com>
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 11/20/2015 07:23 AM
> Subject: SMF/RMF Reporting question
> Sent by: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>
> 
> 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.

Within RMF/SMF, the only thing I can think of is the RMF Monitor III 
Processor Usage report.

Bob

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SMF/RMF Reporting question

[Hardee, Chuck]

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.e

Re: SMF/RMF Reporting question

[Elardus Engelbrecht]

Staller, Allan wrote:

>Sounds like you need to enable SMF Interval Recording  (SYS(...(INTERVAL)) in 
>SMFPRMxx. Set the interval as low as needed. Can be enabled/disabled 
>dynamically to limit the amount of type 30 (1,2,6) and RMF records written to 
>SMF.

Also look at ERBRMFxx for these two: SYNC(RMF,) and INTERVAL().

>As another has suggested, RMF III can also provide some good insights.

Indeed.

Groete / Greetings
Elardus Engelbrecht

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SMF/RMF Reporting question

[Lizette Koehler]

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:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Lizette Koehler
> Sent: Friday, November 20, 2015 6: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
> >

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SMF/RMF Reporting question

[Hardee, Chuck]

Thanks Bob. I'll see if my system programmers know how to run the report.



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 Bob Rutledge
Sent: Friday, November 20, 2015 9:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMF/RMF Reporting question

IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> wrote on 
11/20/2015 07:22:44 AM:

> From: "Hardee, Chuck" <chuck.har...@thermofisher.com>
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 11/20/2015 07:23 AM
> Subject: SMF/RMF Reporting question
> Sent by: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>
> 
> 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.

Within RMF/SMF, the only thing I can think of is the RMF Monitor III 
Processor Usage report.

Bob

--
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

Re: SMF/RMF Reporting question

[Staller, Allan]

Sounds like you need to enable SMF Interval Recording  (SYS(...(INTERVAL)) in 
SMFPRMxx. Set the interval as low as needed.
Can be enabled/disabled dynamically to limit the amount of type 30 (1,2,6) and 
RMF records written to SMF.

As another has suggested, RMF III can also provide some good insights.

HTH,


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.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SMF/RMF Reporting question

[Lizette Koehler]

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

Re: SMF/RMF Reporting question

[Hardee, Chuck]

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
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 9:00 AM
To: IBM-MAIN@LISTSERV.UA.EDU
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:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Lizette Koehler
> Sent: Friday, November 20, 2015 6: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 interna

SMF/RMF Reporting question

[Hardee, Chuck]

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
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.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SMF/RMF Reporting question

[Norman.Hollander]

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, distributi

Re: SMF/RMF Reporting question

[Lucas Rosalen]

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 p

Re: SMF/RMF Reporting question

[Ted MacNEIL]

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