SMF Accounting Question

Jorg Lueke

SMF Accounting Question
Why does Class2 and Class3 Parallel CPU usage gt reported in SMF but not
back to the job that is executing. If I look in the SDSF output I only see the
Class1 CPU time accounted.

The IDUG DB2-L Listserv is only part of your membership in IDUG. DB2-L list archives, the FAQ, and delivery preferences are at http://www.idug.org/lsidug under the Listserv tab. While at the site, you can also access the IDUG Online Learning Center, Tech Library and Code Place, see the latest IDUG conference information, and much more. If you have not yet signed up for Basic Membership in IDUG, available at no cost, click on Member Services at http://www.idug.org/lsms

Mike Bell

Re: SMF Accounting Question
(in response to Jorg Lueke)
Well, the major reason is that those CPU numbers occur in different address spaces. Z/os ties cpu usage to address spaces. If you look at DBM1 address space you can see the cpu increase. What you can't do is tie the cpu usage back to the originating SQL in a job because Z/os mangles all the cpu time for all the jobs together. DB2 manages to collect that information by SQL and pass it back in the DB2 SMF records for you and NO, that is not an inherent feature of Z/os. If you look at the CPU statistics in the base (non-DB2) SMF records, you will see the exact same numbers you saw in SDSF. To get the total usage, you have to use the DB2 SMF accounting records.

Mike
HLS Technologies



-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email] On Behalf Of Jorg Lueke
Sent: Monday, January 21, 2008 10:10 AM
To: [login to unmask email]
Subject: [DB2-L] SMF Accounting Question

Why does Class2 and Class3 Parallel CPU usage gt reported in SMF but not
back to the job that is executing. If I look in the SDSF output I only see the
Class1 CPU time accounted.

The IDUG DB2-L Listserv is only part of your membership in IDUG. DB2-L list archives, the FAQ, and delivery preferences are at http://www.idug.org/lsidug under the Listserv tab. While at the site, you can also access the IDUG Online Learning Center, Tech Library and Code Place, see the latest IDUG conference information, and much more. If you have not yet signed up for Basic Membership in IDUG, available at no cost, click on Member Services at http://www.idug.org/lsms

The IDUG DB2-L Listserv is only part of your membership in IDUG. DB2-L list archives, the FAQ, and delivery preferences are at http://www.idug.org/lsidug under the Listserv tab. While at the site, you can also access the IDUG Online Learning Center, Tech Library and Code Place, see the latest IDUG conference information, and much more. If you have not yet signed up for Basic Membership in IDUG, available at no cost, click on Member Services at http://www.idug.org/lsms

Jorg Lueke

Re: SMF Accounting Question
(in response to Mike Bell)
Thanks Mike, I did not know that. It's very interesting. In this case I was
looking at a utility job. That brings me to a second question. When using
vendor utilities, they often generate parallel tasks as well. Are those typically
structured in a way so that the CPU also does not get reported back to the
job that one is running?


On Mon, 21 Jan 2008 10:56:55 -0600, Mike Bell <[login to unmask email]>
wrote:

>Well, the major reason is that those CPU numbers occur in different address
spaces. Z/os ties cpu usage to address spaces. If you look at DBM1 address
space you can see the cpu increase. What you can't do is tie the cpu usage
back to the originating SQL in a job because Z/os mangles all the cpu time for
all the jobs together. DB2 manages to collect that information by SQL and
pass it back in the DB2 SMF records for you and NO, that is not an inherent
feature of Z/os. If you look at the CPU statistics in the base (non-DB2) SMF
records, you will see the exact same numbers you saw in SDSF. To get the
total usage, you have to use the DB2 SMF accounting records.
>
>Mike
>HLS Technologies
>
>
>
>-----Original Message-----
>From: DB2 Data Base Discussion List [mailto:[login to unmask email] On
Behalf Of Jorg Lueke
>Sent: Monday, January 21, 2008 10:10 AM
>To: [login to unmask email]
>Subject: [DB2-L] SMF Accounting Question
>
>Why does Class2 and Class3 Parallel CPU usage gt reported in SMF but not
>back to the job that is executing. If I look in the SDSF output I only see the
>Class1 CPU time accounted.
>
>The IDUG DB2-L Listserv is only part of your membership in IDUG. DB2-L list
archives, the FAQ, and delivery preferences are at http://www.idug.org/lsidug
under the Listserv tab. While at the site, you can also access the IDUG Online
Learning Center, Tech Library and Code Place, see the latest IDUG conference
information, and much more. If you have not yet signed up for Basic
Membership in IDUG, available at no cost, click on Member Services at
http://www.idug.org/lsms
>
>The IDUG DB2-L Listserv is only part of your membership in IDUG. DB2-L list
archives, the FAQ, and delivery preferences are at http://www.idug.org/lsidug
under the Listserv tab. While at the site, you can also access the IDUG Online
Learning Center, Tech Library and Code Place, see the latest IDUG conference
information, and much more. If you have not yet signed up for Basic
Membership in IDUG, available at no cost, click on Member Services at
http://www.idug.org/lsms

The IDUG DB2-L Listserv is only part of your membership in IDUG. DB2-L list archives, the FAQ, and delivery preferences are at http://www.idug.org/lsidug under the Listserv tab. While at the site, you can also access the IDUG Online Learning Center, Tech Library and Code Place, see the latest IDUG conference information, and much more. If you have not yet signed up for Basic Membership in IDUG, available at no cost, click on Member Services at http://www.idug.org/lsms

Gerald Hodge

Re: SMF Accounting Question
(in response to Jorg Lueke)
When some vendors develop their utilities they are very sensitive to CPU chargeback. Use of Cross Memory Services is a standard way to mask some of these charges. When doing comparisons between vendor products you have to be very careful in assessing the actual CPU costs. If runtime and other factors are about the same then low CPU either means the CPU is being cost to others or the vendor has discovered a way to do the same work at a lower cost. The question then should be how is that cost reduction achieved. Is one product as safe as the other. "There is no such thing as a free lunch."

Gerald Hodge
HLS Technologies.com
www.hlstechnologies.com



-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email] On Behalf Of Jorg Lueke
Sent: Monday, January 21, 2008 11:17 AM
To: [login to unmask email]
Subject: Re: [DB2-L] SMF Accounting Question

Thanks Mike, I did not know that. It's very interesting. In this case I was
looking at a utility job. That brings me to a second question. When using
vendor utilities, they often generate parallel tasks as well. Are those typically
structured in a way so that the CPU also does not get reported back to the
job that one is running?


On Mon, 21 Jan 2008 10:56:55 -0600, Mike Bell <[login to unmask email]>
wrote:

>Well, the major reason is that those CPU numbers occur in different address
spaces. Z/os ties cpu usage to address spaces. If you look at DBM1 address
space you can see the cpu increase. What you can't do is tie the cpu usage
back to the originating SQL in a job because Z/os mangles all the cpu time for
all the jobs together. DB2 manages to collect that information by SQL and
pass it back in the DB2 SMF records for you and NO, that is not an inherent
feature of Z/os. If you look at the CPU statistics in the base (non-DB2) SMF
records, you will see the exact same numbers you saw in SDSF. To get the
total usage, you have to use the DB2 SMF accounting records.
>
>Mike
>HLS Technologies

The IDUG DB2-L Listserv is only part of your membership in IDUG. DB2-L list archives, the FAQ, and delivery preferences are at http://www.idug.org/lsidug under the Listserv tab. While at the site, you can also access the IDUG Online Learning Center, Tech Library and Code Place, see the latest IDUG conference information, and much more. If you have not yet signed up for Basic Membership in IDUG, available at no cost, click on Member Services at http://www.idug.org/lsms

Jorg Lueke

Re: SMF Accounting Question
(in response to Gerald Hodge)
So is there a way, preferably a simple way, to understand the full cost of such
as job?

On Mon, 21 Jan 2008 11:40:08 -0600, Gerald Hodge
<[login to unmask email]> wrote:

>When some vendors develop their utilities they are very sensitive to CPU
chargeback. Use of Cross Memory Services is a standard way to mask some of
these charges. When doing comparisons between vendor products you have
to be very careful in assessing the actual CPU costs. If runtime and other
factors are about the same then low CPU either means the CPU is being cost
to others or the vendor has discovered a way to do the same work at a lower
cost. The question then should be how is that cost reduction achieved. Is
one product as safe as the other. "There is no such thing as a free lunch."
>
>Gerald Hodge
>HLS Technologies.com
>www.hlstechnologies.com
>
>
>
>-----Original Message-----
>From: DB2 Data Base Discussion List [mailto:[login to unmask email] On
Behalf Of Jorg Lueke
>Sent: Monday, January 21, 2008 11:17 AM
>To: [login to unmask email]
>Subject: Re: [DB2-L] SMF Accounting Question
>
>Thanks Mike, I did not know that. It's very interesting. In this case I was
>looking at a utility job. That brings me to a second question. When using
>vendor utilities, they often generate parallel tasks as well. Are those typically
>structured in a way so that the CPU also does not get reported back to the
>job that one is running?
>
>
>On Mon, 21 Jan 2008 10:56:55 -0600, Mike Bell <[login to unmask email]>
>wrote:
>
>>Well, the major reason is that those CPU numbers occur in different address
>spaces. Z/os ties cpu usage to address spaces. If you look at DBM1 address
>space you can see the cpu increase. What you can't do is tie the cpu usage
>back to the originating SQL in a job because Z/os mangles all the cpu time for
>all the jobs together. DB2 manages to collect that information by SQL and
>pass it back in the DB2 SMF records for you and NO, that is not an inherent
>feature of Z/os. If you look at the CPU statistics in the base (non-DB2) SMF
>records, you will see the exact same numbers you saw in SDSF. To get the
>total usage, you have to use the DB2 SMF accounting records.
>>
>>Mike
>>HLS Technologies
>
>The IDUG DB2-L Listserv is only part of your membership in IDUG. DB2-L list
archives, the FAQ, and delivery preferences are at http://www.idug.org/lsidug
under the Listserv tab. While at the site, you can also access the IDUG Online
Learning Center, Tech Library and Code Place, see the latest IDUG conference
information, and much more. If you have not yet signed up for Basic
Membership in IDUG, available at no cost, click on Member Services at
http://www.idug.org/lsms

The IDUG DB2-L Listserv is only part of your membership in IDUG. DB2-L list archives, the FAQ, and delivery preferences are at http://www.idug.org/lsidug under the Listserv tab. While at the site, you can also access the IDUG Online Learning Center, Tech Library and Code Place, see the latest IDUG conference information, and much more. If you have not yet signed up for Basic Membership in IDUG, available at no cost, click on Member Services at http://www.idug.org/lsms

Mike Bell

Re: SMF Accounting Question
(in response to Jorg Lueke)
Parallel tasks can be generated multiple ways. For the 2 points of discussion here I will call them SQL parallel and utility parallel.

SQL parallel takes an SQL statement from a program and passes portions of the work to be processed to existing DB2 subsystems. Those DB2 subsystems then process the portion of the work and store the results in temp storage ( what used to be DSNDB07). The work that is processed runs as an SRB in the DBM1 address space so it will show up as SRB time in all the DBM1 address that participated. Only DB2 can collect all the cpu time used and produce a composite report of total cpu used.

Utility parallel task can be coded to generate parallel task 2 different ways.
The Z/os tasks can be created as dependent TCB's in the same address space or SRB's in the same address space. I do NOT code these kinds of code. I know about them from before DBA days but that is all. Supposedly there are advantages to creating SRB's versus dependent TCB's, but you would have to ask over on IBM-MAIN listserv or the actual DB2 utility companies to find out. The results when a utility uses dependent TCB's are that all the CPU time shows up as normal SDSF/SMF (not DB2) cpu time. If they were coded to use SRB's, then you have to add the SRB time to the basic cpu time. My jobs show this as

TCB SRB CLOCK
3.49 .21 9.6

SRB time also includes IO processing for page fixing, and lots of other z/os overhead.

BTW, none of these methods are the equivalent of UNIX SPAWN operative which is a whole different procedure.

Mike
HLS Technologies

-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email] On Behalf Of Jorg Lueke
Sent: Monday, January 21, 2008 11:17 AM
To: [login to unmask email]
Subject: Re: [DB2-L] SMF Accounting Question

Thanks Mike, I did not know that. It's very interesting. In this case I was
looking at a utility job. That brings me to a second question. When using
vendor utilities, they often generate parallel tasks as well. Are those typically
structured in a way so that the CPU also does not get reported back to the
job that one is running?


On Mon, 21 Jan 2008 10:56:55 -0600, Mike Bell <[login to unmask email]>
wrote:

>Well, the major reason is that those CPU numbers occur in different address
spaces. Z/os ties cpu usage to address spaces. If you look at DBM1 address
space you can see the cpu increase. What you can't do is tie the cpu usage
back to the originating SQL in a job because Z/os mangles all the cpu time for
all the jobs together. DB2 manages to collect that information by SQL and
pass it back in the DB2 SMF records for you and NO, that is not an inherent
feature of Z/os. If you look at the CPU statistics in the base (non-DB2) SMF
records, you will see the exact same numbers you saw in SDSF. To get the
total usage, you have to use the DB2 SMF accounting records.
>
>Mike
>HLS Technologies
>
>
>
>-----Original Message-----
>From: DB2 Data Base Discussion List [mailto:[login to unmask email] On
Behalf Of Jorg Lueke
>Sent: Monday, January 21, 2008 10:10 AM
>To: [login to unmask email]
>Subject: [DB2-L] SMF Accounting Question
>
>Why does Class2 and Class3 Parallel CPU usage gt reported in SMF but not
>back to the job that is executing. If I look in the SDSF output I only see the
>Class1 CPU time accounted.
>
>The IDUG DB2-L Listserv is only part of your membership in IDUG. DB2-L list
archives, the FAQ, and delivery preferences are at http://www.idug.org/lsidug
under the Listserv tab. While at the site, you can also access the IDUG Online
Learning Center, Tech Library and Code Place, see the latest IDUG conference
information, and much more. If you have not yet signed up for Basic
Membership in IDUG, available at no cost, click on Member Services at
http://www.idug.org/lsms
>
>The IDUG DB2-L Listserv is only part of your membership in IDUG. DB2-L list
archives, the FAQ, and delivery preferences are at http://www.idug.org/lsidug
under the Listserv tab. While at the site, you can also access the IDUG Online
Learning Center, Tech Library and Code Place, see the latest IDUG conference
information, and much more. If you have not yet signed up for Basic
Membership in IDUG, available at no cost, click on Member Services at
http://www.idug.org/lsms

The IDUG DB2-L Listserv is only part of your membership in IDUG. DB2-L list archives, the FAQ, and delivery preferences are at http://www.idug.org/lsidug under the Listserv tab. While at the site, you can also access the IDUG Online Learning Center, Tech Library and Code Place, see the latest IDUG conference information, and much more. If you have not yet signed up for Basic Membership in IDUG, available at no cost, click on Member Services at http://www.idug.org/lsms

The IDUG DB2-L Listserv is only part of your membership in IDUG. DB2-L list archives, the FAQ, and delivery preferences are at http://www.idug.org/lsidug under the Listserv tab. While at the site, you can also access the IDUG Online Learning Center, Tech Library and Code Place, see the latest IDUG conference information, and much more. If you have not yet signed up for Basic Membership in IDUG, available at no cost, click on Member Services at http://www.idug.org/lsms

Jorg Lueke

Re: SMF Accounting Question
(in response to Mike Bell)
Mike,

This is working a little bit differently. For the IBM utility the parallel tasks do
not show up in the job in SDSF under TCB or SRB, they are accounted for in
the Class2 and Class3 parallel CPU fields. The vendor utilities don't show up in
either place. So either they are magical and take 10% the CPU of IBM utilities
or they hide the CPU time in a different task.

On Mon, 21 Jan 2008 12:07:37 -0600, Mike Bell <[login to unmask email]>
wrote:

>
>Utility parallel task can be coded to generate parallel task 2 different ways.
>The Z/os tasks can be created as dependent TCB's in the same address
space or SRB's in the same address space. I do NOT code these kinds of
code. I know about them from before DBA days but that is all. Supposedly
there are advantages to creating SRB's versus dependent TCB's, but you
would have to ask over on IBM-MAIN listserv or the actual DB2 utility
companies to find out. The results when a utility uses dependent TCB's are
that all the CPU time shows up as normal SDSF/SMF (not DB2) cpu time. If
they were coded to use SRB's, then you have to add the SRB time to the
basic cpu time. My jobs show this as
>
> TCB SRB CLOCK
> 3.49 .21 9.6
>

The IDUG DB2-L Listserv is only part of your membership in IDUG. DB2-L list archives, the FAQ, and delivery preferences are at http://www.idug.org/lsidug under the Listserv tab. While at the site, you can also access the IDUG Online Learning Center, Tech Library and Code Place, see the latest IDUG conference information, and much more. If you have not yet signed up for Basic Membership in IDUG, available at no cost, click on Member Services at http://www.idug.org/lsms

Mike Bell

Re: SMF Accounting Question
(in response to Jorg Lueke)
It has been a while since I did a full out research on what is going on in the utilities. GTF is the tool to figure this kind of stuff out.
1. DB2 can spawn SRB's to anywhere - when you are authorized (APF auth - ask a systems programmer what that means), which DB2 is, you can do all kinds of things.
2. when you are authorized, you can even spawn SRB's or tasks that don't update the fields that are reported as CPU time. That is one way to make sure you always win the cpu billing calculation.

DB2 is at least reporting on full cpu utilized but not in the standard mannor.

Mike

-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email] On Behalf Of Jorg Lueke
Sent: Monday, January 21, 2008 1:42 PM
To: [login to unmask email]
Subject: Re: [DB2-L] SMF Accounting Question

Mike,

This is working a little bit differently. For the IBM utility the parallel tasks do
not show up in the job in SDSF under TCB or SRB, they are accounted for in
the Class2 and Class3 parallel CPU fields. The vendor utilities don't show up in
either place. So either they are magical and take 10% the CPU of IBM utilities
or they hide the CPU time in a different task.

On Mon, 21 Jan 2008 12:07:37 -0600, Mike Bell <[login to unmask email]>
wrote:

>
>Utility parallel task can be coded to generate parallel task 2 different ways.
>The Z/os tasks can be created as dependent TCB's in the same address
space or SRB's in the same address space. I do NOT code these kinds of
code. I know about them from before DBA days but that is all. Supposedly
there are advantages to creating SRB's versus dependent TCB's, but you
would have to ask over on IBM-MAIN listserv or the actual DB2 utility
companies to find out. The results when a utility uses dependent TCB's are
that all the CPU time shows up as normal SDSF/SMF (not DB2) cpu time. If
they were coded to use SRB's, then you have to add the SRB time to the
basic cpu time. My jobs show this as
>
> TCB SRB CLOCK
> 3.49 .21 9.6
>

The IDUG DB2-L Listserv is only part of your membership in IDUG. DB2-L list archives, the FAQ, and delivery preferences are at http://www.idug.org/lsidug under the Listserv tab. While at the site, you can also access the IDUG Online Learning Center, Tech Library and Code Place, see the latest IDUG conference information, and much more. If you have not yet signed up for Basic Membership in IDUG, available at no cost, click on Member Services at http://www.idug.org/lsms

The IDUG DB2-L Listserv is only part of your membership in IDUG. DB2-L list archives, the FAQ, and delivery preferences are at http://www.idug.org/lsidug under the Listserv tab. While at the site, you can also access the IDUG Online Learning Center, Tech Library and Code Place, see the latest IDUG conference information, and much more. If you have not yet signed up for Basic Membership in IDUG, available at no cost, click on Member Services at http://www.idug.org/lsms

Jorg Lueke

Re: SMF Accounting Question
(in response to Mike Bell)
Fascinating! You think you know something after ten years, and then it turns
out you really have no idea!

Hopefully we gave Strobe and it can trace this too. GTF would be a bit harder
to work with.

I agree that IBM it reporting all the CPU, it was just a matter of understanding
where it was. Hopefully the vendor is also reporting all the CPU somewhere.


On Mon, 21 Jan 2008 14:18:25 -0600, Mike Bell <[login to unmask email]>
wrote:

>It has been a while since I did a full out research on what is going on in the
utilities. GTF is the tool to figure this kind of stuff out.
>1. DB2 can spawn SRB's to anywhere - when you are authorized (APF auth -
ask a systems programmer what that means), which DB2 is, you can do all
kinds of things.
>2. when you are authorized, you can even spawn SRB's or tasks that don't
update the fields that are reported as CPU time. That is one way to make sure
you always win the cpu billing calculation.
>
>DB2 is at least reporting on full cpu utilized but not in the standard mannor.
>
>Mike
>
>-----Original Message-----
>From: DB2 Data Base Discussion List [mailto:[login to unmask email] On
Behalf Of Jorg Lueke
>Sent: Monday, January 21, 2008 1:42 PM
>To: [login to unmask email]
>Subject: Re: [DB2-L] SMF Accounting Question
>
>Mike,
>
>This is working a little bit differently. For the IBM utility the parallel tasks do
>not show up in the job in SDSF under TCB or SRB, they are accounted for in
>the Class2 and Class3 parallel CPU fields. The vendor utilities don't show up in
>either place. So either they are magical and take 10% the CPU of IBM utilities
>or they hide the CPU time in a different task.
>

The IDUG DB2-L Listserv is only part of your membership in IDUG. DB2-L list archives, the FAQ, and delivery preferences are at http://www.idug.org/lsidug under the Listserv tab. While at the site, you can also access the IDUG Online Learning Center, Tech Library and Code Place, see the latest IDUG conference information, and much more. If you have not yet signed up for Basic Membership in IDUG, available at no cost, click on Member Services at http://www.idug.org/lsms

Joel Goldstein

Re: SMF Accounting Question
(in response to Jorg Lueke)
There too, it depends......
If the utility uses a lot of prefetch, that prefetch IO cost is charged to
DBM1.


Regards,
Joel


Joel Goldstein
Responsive Systems
Buffer Pool Tool for DB2, the worldwide industry standard
Performance software that works......
Predicts Group Buffer Pool performance too!
www.responsivesystems.com
tel. (732) 972-1261
fax.(732) 972-9416
----- Original Message -----
From: "Jorg Lueke" <[login to unmask email]>
Newsgroups: bit.listserv.db2-l
To: <[login to unmask email]>
Sent: Monday, January 21, 2008 3:47 PM
Subject: Re: [DB2-L] SMF Accounting Question


> Fascinating! You think you know something after ten years, and then it
> turns
> out you really have no idea!
>
> Hopefully we gave Strobe and it can trace this too. GTF would be a bit
> harder
> to work with.
>
> I agree that IBM it reporting all the CPU, it was just a matter of
> understanding
> where it was. Hopefully the vendor is also reporting all the CPU
> somewhere.
>
>
> On Mon, 21 Jan 2008 14:18:25 -0600, Mike Bell <[login to unmask email]>
> wrote:
>
>>It has been a while since I did a full out research on what is going on in
>>the
> utilities. GTF is the tool to figure this kind of stuff out.
>>1. DB2 can spawn SRB's to anywhere - when you are authorized (APF auth -
> ask a systems programmer what that means), which DB2 is, you can do all
> kinds of things.
>>2. when you are authorized, you can even spawn SRB's or tasks that don't
> update the fields that are reported as CPU time. That is one way to make
> sure
> you always win the cpu billing calculation.
>>
>>DB2 is at least reporting on full cpu utilized but not in the standard
>>mannor.
>>
>>Mike
>>
>>-----Original Message-----
>>From: DB2 Data Base Discussion List [mailto:[login to unmask email] On
> Behalf Of Jorg Lueke
>>Sent: Monday, January 21, 2008 1:42 PM
>>To: [login to unmask email]
>>Subject: Re: [DB2-L] SMF Accounting Question
>>
>>Mike,
>>
>>This is working a little bit differently. For the IBM utility the
>>parallel tasks do
>>not show up in the job in SDSF under TCB or SRB, they are accounted for in
>>the Class2 and Class3 parallel CPU fields. The vendor utilities don't
>>show up in
>>either place. So either they are magical and take 10% the CPU of IBM
>>utilities
>>or they hide the CPU time in a different task.
>>
>
> The IDUG DB2-L Listserv is only part of your membership in IDUG. DB2-L
> list archives, the FAQ, and delivery preferences are at
> http://www.idug.org/lsidug under the Listserv tab. While at the site, you
> can also access the IDUG Online Learning Center, Tech Library and Code
> Place, see the latest IDUG conference information, and much more. If you
> have not yet signed up for Basic Membership in IDUG, available at no cost,
> click on Member Services at http://www.idug.org/lsms
>
>

The IDUG DB2-L Listserv is only part of your membership in IDUG. DB2-L list archives, the FAQ, and delivery preferences are at http://www.idug.org/lsidug under the Listserv tab. While at the site, you can also access the IDUG Online Learning Center, Tech Library and Code Place, see the latest IDUG conference information, and much more. If you have not yet signed up for Basic Membership in IDUG, available at no cost, click on Member Services at http://www.idug.org/lsms

Jorg Lueke

Re: SMF Accounting Question
(in response to Joel Goldstein)
I'm thinking, or hoping, that the vendor is using direct access both to read the
DB2 Vsam files and write out the sequential copy.

On Mon, 21 Jan 2008 15:57:36 -0500, Joel Goldstein - Responsive Systems
<[login to unmask email]> wrote:

>There too, it depends......
>If the utility uses a lot of prefetch, that prefetch IO cost is charged to
>DBM1.
>
>
>Regards,
>Joel
>
>
>Joel Goldstein
>Responsive Systems
>Buffer Pool Tool for DB2, the worldwide industry standard
> Performance software that works......
> Predicts Group Buffer Pool performance too!
>www.responsivesystems.com
>tel. (732) 972-1261
>fax.(732) 972-9416
>----- Original Message -----
>From: "Jorg Lueke" <[login to unmask email]>
>Newsgroups: bit.listserv.db2-l
>To: <[login to unmask email]>
>Sent: Monday, January 21, 2008 3:47 PM
>Subject: Re: [DB2-L] SMF Accounting Question
>
>
>> Fascinating! You think you know something after ten years, and then it
>> turns
>> out you really have no idea!
>>
>> Hopefully we gave Strobe and it can trace this too. GTF would be a bit
>> harder
>> to work with.
>>
>> I agree that IBM it reporting all the CPU, it was just a matter of
>> understanding
>> where it was. Hopefully the vendor is also reporting all the CPU
>> somewhere.
>>
>>
>> On Mon, 21 Jan 2008 14:18:25 -0600, Mike Bell <[login to unmask email]>
>> wrote:
>>
>>>It has been a while since I did a full out research on what is going on in
>>>the
>> utilities. GTF is the tool to figure this kind of stuff out.
>>>1. DB2 can spawn SRB's to anywhere - when you are authorized (APF
auth -
>> ask a systems programmer what that means), which DB2 is, you can do all
>> kinds of things.
>>>2. when you are authorized, you can even spawn SRB's or tasks that don't
>> update the fields that are reported as CPU time. That is one way to make
>> sure
>> you always win the cpu billing calculation.
>>>
>>>DB2 is at least reporting on full cpu utilized but not in the standard
>>>mannor.
>>>
>>>Mike
>>>
>>>-----Original Message-----
>>>From: DB2 Data Base Discussion List [mailto:[login to unmask email] On
>> Behalf Of Jorg Lueke
>>>Sent: Monday, January 21, 2008 1:42 PM
>>>To: [login to unmask email]
>>>Subject: Re: [DB2-L] SMF Accounting Question
>>>
>>>Mike,
>>>
>>>This is working a little bit differently. For the IBM utility the
>>>parallel tasks do
>>>not show up in the job in SDSF under TCB or SRB, they are accounted for
in
>>>the Class2 and Class3 parallel CPU fields. The vendor utilities don't
>>>show up in
>>>either place. So either they are magical and take 10% the CPU of IBM
>>>utilities
>>>or they hide the CPU time in a different task.
>>>
>>
>> The IDUG DB2-L Listserv is only part of your membership in IDUG. DB2-L
>> list archives, the FAQ, and delivery preferences are at
>> http://www.idug.org/lsidug under the Listserv tab. While at the site, you
>> can also access the IDUG Online Learning Center, Tech Library and Code
>> Place, see the latest IDUG conference information, and much more. If you
>> have not yet signed up for Basic Membership in IDUG, available at no cost,
>> click on Member Services at http://www.idug.org/lsms
>>
>>
>
>The IDUG DB2-L Listserv is only part of your membership in IDUG. DB2-L list
archives, the FAQ, and delivery preferences are at http://www.idug.org/lsidug
under the Listserv tab. While at the site, you can also access the IDUG Online
Learning Center, Tech Library and Code Place, see the latest IDUG conference
information, and much more. If you have not yet signed up for Basic
Membership in IDUG, available at no cost, click on Member Services at
http://www.idug.org/lsms

The IDUG DB2-L Listserv is only part of your membership in IDUG. DB2-L list archives, the FAQ, and delivery preferences are at http://www.idug.org/lsidug under the Listserv tab. While at the site, you can also access the IDUG Online Learning Center, Tech Library and Code Place, see the latest IDUG conference information, and much more. If you have not yet signed up for Basic Membership in IDUG, available at no cost, click on Member Services at http://www.idug.org/lsms

Chad Walmer

Re: SMF Accounting Question
(in response to Jorg Lueke)
Jorg,
Don't forget that the IBM utilities use the database as their core data access method. In other words, they perform GETPAGEs and invoke the services of the Buffer Manager, Data Manager, etc to process the data. OEM vendors generally process the linear VSAM data sets directly rather than use the database. So their DB2 times will be relatively small (just some general accounting and recording) compared to the IBM utilities.

While the 10% difference in CPU you are observing seems quite drastic, the OEM vendors are using direct access method services with very little overhead where as IBM, by way of the database engine, will have a much longer CPU path to process the same data.

Chad Walmer

-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email] On Behalf Of Jorg Lueke
Sent: Monday, January 21, 2008 2:42 PM
To: [login to unmask email]
Subject: Re: [DB2-L] SMF Accounting Question

Mike,

This is working a little bit differently. For the IBM utility the parallel tasks do
not show up in the job in SDSF under TCB or SRB, they are accounted for in
the Class2 and Class3 parallel CPU fields. The vendor utilities don't show up in
either place. So either they are magical and take 10% the CPU of IBM utilities
or they hide the CPU time in a different task.

On Mon, 21 Jan 2008 12:07:37 -0600, Mike Bell <[login to unmask email]>
wrote:

>
>Utility parallel task can be coded to generate parallel task 2 different ways.
>The Z/os tasks can be created as dependent TCB's in the same address
space or SRB's in the same address space. I do NOT code these kinds of
code. I know about them from before DBA days but that is all. Supposedly
there are advantages to creating SRB's versus dependent TCB's, but you
would have to ask over on IBM-MAIN listserv or the actual DB2 utility
companies to find out. The results when a utility uses dependent TCB's are
that all the CPU time shows up as normal SDSF/SMF (not DB2) cpu time. If
they were coded to use SRB's, then you have to add the SRB time to the
basic cpu time. My jobs show this as
>
> TCB SRB CLOCK
> 3.49 .21 9.6
>

The IDUG DB2-L Listserv is only part of your membership in IDUG. DB2-L list archives, the FAQ, and delivery preferences are at http://www.idug.org/lsidug under the Listserv tab. While at the site, you can also access the IDUG Online Learning Center, Tech Library and Code Place, see the latest IDUG conference information, and much more. If you have not yet signed up for Basic Membership in IDUG, available at no cost, click on Member Services at http://www.idug.org/lsms

Disclaimer: This e-mail message is intended only for the personal use of
the recipient(s) named above. If you are not an intended recipient, you
may not review, copy or distribute this message. If you have received this
communication in error, please notify us immediately by e-mail and delete
the original message.

This e-mail expresses views only of the sender, which are not to be
attributed to Rite Aid Corporation and may not be copied or distributed
without this statement.

The IDUG DB2-L Listserv is only part of your membership in IDUG. DB2-L list archives, the FAQ, and delivery preferences are at http://www.idug.org/lsidug under the Listserv tab. While at the site, you can also access the IDUG Online Learning Center, Tech Library and Code Place, see the latest IDUG conference information, and much more. If you have not yet signed up for Basic Membership in IDUG, available at no cost, click on Member Services at http://www.idug.org/lsms

Chris White

Re: SMF Accounting Question
(in response to Chad Walmer)
I don't disagree with any of the previous answers... just offering a simple rule
of thumb someone told me years ago. I don't know if it has exceptions, but I
have found it to be useful and generally accurate...

Synchronous activities associated with any allied agent are charged to AA
address space. Asynchronous activities (e.g. prefetch) are charged
elsewhere, usually DBM1.

Regards,
Chris White
Ex-DB2 z/OS Sysprog
Caterpillar inc.

These are just my opinions, not my employer's and blah, blah, blah...

===<snip>===>
On Mon, 21 Jan 2008 15:57:36 -0500, Joel Goldstein - Responsive Systems
<[login to unmask email]> wrote:

>There too, it depends......
>If the utility uses a lot of prefetch, that prefetch IO cost is charged to
>DBM1.
>
>
>Regards,
>Joel
>
>
>Joel Goldstein
>Responsive Systems
>Buffer Pool Tool for DB2, the worldwide industry standard
> Performance software that works......
> Predicts Group Buffer Pool performance too!
>www.responsivesystems.com
>tel. (732) 972-1261
>fax.(732) 972-9416
>----- Original Message -----
>From: "Jorg Lueke" <[login to unmask email]>
>Newsgroups: bit.listserv.db2-l
>To: <[login to unmask email]>
>Sent: Monday, January 21, 2008 3:47 PM
>Subject: Re: [DB2-L] SMF Accounting Question
>
>
>> Fascinating! You think you know something after ten years, and then it
>> turns
>> out you really have no idea!
>>
>> Hopefully we gave Strobe and it can trace this too. GTF would be a bit
>> harder
>> to work with.
>>
>> I agree that IBM it reporting all the CPU, it was just a matter of
>> understanding
>> where it was. Hopefully the vendor is also reporting all the CPU
>> somewhere.
>>
>>
>> On Mon, 21 Jan 2008 14:18:25 -0600, Mike Bell <[login to unmask email]>
>> wrote:
>>
>>>It has been a while since I did a full out research on what is going on in
>>>the
>> utilities. GTF is the tool to figure this kind of stuff out.
>>>1. DB2 can spawn SRB's to anywhere - when you are authorized (APF
auth -
>> ask a systems programmer what that means), which DB2 is, you can do all
>> kinds of things.
>>>2. when you are authorized, you can even spawn SRB's or tasks that don't
>> update the fields that are reported as CPU time. That is one way to make
>> sure
>> you always win the cpu billing calculation.
>>>
>>>DB2 is at least reporting on full cpu utilized but not in the standard
>>>mannor.
>>>
>>>Mike
>>>
>>>-----Original Message-----
>>>From: DB2 Data Base Discussion List [mailto:[login to unmask email] On
>> Behalf Of Jorg Lueke
>>>Sent: Monday, January 21, 2008 1:42 PM
>>>To: [login to unmask email]
>>>Subject: Re: [DB2-L] SMF Accounting Question
>>>
>>>Mike,
>>>
>>>This is working a little bit differently. For the IBM utility the
>>>parallel tasks do
>>>not show up in the job in SDSF under TCB or SRB, they are accounted for
in
>>>the Class2 and Class3 parallel CPU fields. The vendor utilities don't
>>>show up in
>>>either place. So either they are magical and take 10% the CPU of IBM
>>>utilities
>>>or they hide the CPU time in a different task.
>>>
>>
>> The IDUG DB2-L Listserv is only part of your membership in IDUG. DB2-L
>> list archives, the FAQ, and delivery preferences are at
>> http://www.idug.org/lsidug under the Listserv tab. While at the site, you
>> can also access the IDUG Online Learning Center, Tech Library and Code
>> Place, see the latest IDUG conference information, and much more. If you
>> have not yet signed up for Basic Membership in IDUG, available at no cost,
>> click on Member Services at http://www.idug.org/lsms
>>
>>
>
>The IDUG DB2-L Listserv is only part of your membership in IDUG. DB2-L list
archives, the FAQ, and delivery preferences are at http://www.idug.org/lsidug
under the Listserv tab. While at the site, you can also access the IDUG Online
Learning Center, Tech Library and Code Place, see the latest IDUG conference
information, and much more. If you have not yet signed up for Basic
Membership in IDUG, available at no cost, click on Member Services at
http://www.idug.org/lsms

The IDUG DB2-L Listserv is only part of your membership in IDUG. DB2-L list archives, the FAQ, and delivery preferences are at http://www.idug.org/lsidug under the Listserv tab. While at the site, you can also access the IDUG Online Learning Center, Tech Library and Code Place, see the latest IDUG conference information, and much more. If you have not yet signed up for Basic Membership in IDUG, available at no cost, click on Member Services at http://www.idug.org/lsms