DB2-L Digest - 3 Dec 2010 to 4 Dec 2010 (#2010-327)

Dave Edwards

DB2-L Digest - 3 Dec 2010 to 4 Dec 2010 (#2010-327)
----- Original Message -----
From: "DB2-L automatic digest system" <[login to unmask email]>
To: <[login to unmask email]>
Sent: Saturday, December 04, 2010 1:00 AM
Subject: DB2-L Digest - 3 Dec 2010 to 4 Dec 2010 (#2010-327)


There are 23 messages totaling 8674 lines in this issue.

Topics of the day:

1. Service Units for a Dynamic Bind
2. CICS/DB2 Accounting Question (4)
3. AW: Service Units for a Dynamic Bind (12)
4. 24 X 7 DB2 & replication server (3)
5. Creating the same database but??
6. [AD] Cogito DB2 z/OS Webinar Series: Accelerate DB2 9 or 10 Migration
while Reducing Risk
7. Houston Area DB2 User Group meeting has been scheduled for January

----------------------------------------------------------------------

Date: Fri, 3 Dec 2010 02:53:17 -0500
From: Adam Baldwin <[login to unmask email]>
Subject: Re: Service Units for a Dynamic Bind

Jay, I can't give you a ROT but this may be of interest to you:

http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/FLASH10609

I imagine that you're already aware of this but, if not, it could be of use
to you.

Cheers, Adam

_____________________________________________________________________
* IDUG North America * Anaheim, California * May 2-6 2011 *
http://IDUG.ORG/NA *
* Your only source for independent, unbiased, and trusted DB2 information.
*
** The best DB2 technical sessions in the world
** Independent, not-for-profit, User Run - the IDUG difference!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is
the home of IDUG's Listserv

------------------------------

Date: Fri, 3 Dec 2010 09:00:28 +0100
From: Max Scarpa <[login to unmask email]>
Subject: Re: CICS/DB2 Accounting Question

It's the classic problem happening when you implement protected thread,
the stacking of threads. You could use (ACCT time/number of threads) to
have a rough evaluation about tx times. But it's better to use ACCOUNTREC
to cut SMF records for every tx/UOW etc. (Once you had to use TOKENE
parameter,). But protected thread need monitoring so if you need more
infos see for example:

- CICS-DB2 Performance:Hints, Tips, and War Stories by Robert Catterall

- Exploiting the CICS-DB2 borderland by Svenn-Aage
Sønderskov

- DB2/CICS interface - A view of interface between DB2 / CICS by Patricia
Townsend (good for monitoring suggestions)

HTH

Max Scarpa

The Fifth Rule: You have taken yourself too seriously.

_____________________________________________________________________
* IDUG North America * Anaheim, California * May 2-6 2011 *
http://IDUG.ORG/NA *
* Your only source for independent, unbiased, and trusted DB2 information.
*
** The best DB2 technical sessions in the world
** Independent, not-for-profit, User Run - the IDUG difference!
_____________________________________________________________________

------------------------------

Date: Fri, 3 Dec 2010 11:02:59 +0100
From: Walter Janißen <[login to unmask email]>
Subject: AW: Service Units for a Dynamic Bind

Ray

I am not sure, if I understand, what you were telling. Do you mean, that the
dynamic bind is performed by the DDF-address-space?


regards
Walter Janißen

ITERGO Informationstechnologie GmbH
Anwendungsentwicklung
Systeme Laufzeitarchitektur
Victoriaplatz 2
D-40198 Düsseldorf
[login to unmask email]<mailto:[login to unmask email]>

Vorsitzender des Aufsichtsrats: Jürgen Vetter
Geschäftsführung: Dr. Bettina Anders (Vorsitzende),
Ina Kirchhof, Dr. Christian Nymphius, Dr. Michael Regauer, Wolfgang Schön
Sitz: Düsseldorf, Handelsregister: Amtsgericht Düsseldorf, HRB 37996



________________________________
Von: IDUG DB2-L [mailto:[login to unmask email] Im Auftrag von Reavill, Jay
Gesendet: Mittwoch, 1. Dezember 2010 19:31
An: [login to unmask email]
Betreff: [DB2-L] Service Units for a Dynamic Bind

Anyone have a ROT on the amount of service units it takes to perform a
dynamic bind? I'm sure it fluctuates depending on the complexity of the
SQL, but we're trying to make sure that we have enough juice being allotted
to our period 1 WLM service classes for the distributed work coming in so
that they don't get "stuck" due to CPU constraints and end up holding locks
on system objects while in the middle of a dynamic bind. We also don't want
to thru too much juice their way because we don't want them to dominate
unnecessarily. We're just trying to avoid system level contention.

As always, Thanks!
Jay

------------------------------------------------------------------------
Jay Reavill
DBA
Fidelity National Information Services, Inc.
11601 Roosevelt Blvd., St. Petersburg, FL. 33716
Office: 727-227-2144 | Cell: 727-215-5794
[login to unmask email]<mailto:[login to unmask email]>
------------------------------------------------------------------------

_____________

The information contained in this message is proprietary and/or
confidential. If you are not the intended recipient, please: (i) delete the
message and all copies; (ii) do not disclose, distribute or use the message
in any manner; and (iii) notify the sender immediately. In addition, please
be aware that any message addressed to our domain is subject to archiving
and review by persons other than the intended recipient. Thank you.
_____________

________________________________

[ http://www.idug.org/images/banners/idug_2011.gif ] < http://www.idug.org >

The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are
not already an IDUG member, please register
here. < http://www.idug.org/register >

_____________________________________________________________________
* IDUG North America * Anaheim, California * May 2-6 2011 *
http://IDUG.ORG/NA *
* Your only source for independent, unbiased, and trusted DB2 information.
*
** The best DB2 technical sessions in the world
** Independent, not-for-profit, User Run - the IDUG difference!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is
the home of IDUG's Listserv

------------------------------

Date: Fri, 3 Dec 2010 11:26:03 +0100
From: Jan Vanbrabant <[login to unmask email]>
Subject: Re: CICS/DB2 Accounting Question

Hi Max,

*Re. *

*CICS-DB2 Performance: Hints, Tips, and War Stories (Robert Catterall) *



I googled

http://www.share.org/proceedings/sh97/data/S1355.PDF

But: not found and it's redirecting to the SHARE home page.
This presentation is from a previous Share, hence not available, unless you
are a share memeber.
Though being GSE, you can't have access to previous proceedings. An old
pain................

Can you (or someone alse) route me (and probably others) to Robert's
presentation?

Thanks.
jan

_____________________________________________________________________
* IDUG North America * Anaheim, California * May 2-6 2011 *
http://IDUG.ORG/NA *
* Your only source for independent, unbiased, and trusted DB2 information.
*
** The best DB2 technical sessions in the world
** Independent, not-for-profit, User Run - the IDUG difference!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is
the home of IDUG's Listserv

------------------------------

Date: Fri, 3 Dec 2010 11:37:52 +0100
From: Max Scarpa <[login to unmask email]>
Subject: Re: CICS/DB2 Accounting Question

Sent, hope you received it . It0s an old article, I think there are more
recent versions but I've to dig more.

Max


_____________________________________________________________________
* IDUG North America * Anaheim, California * May 2-6 2011 *
http://IDUG.ORG/NA *
* Your only source for independent, unbiased, and trusted DB2 information.
*
** The best DB2 technical sessions in the world
** Independent, not-for-profit, User Run - the IDUG difference!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is
the home of IDUG's Listserv

------------------------------

Date: Fri, 3 Dec 2010 13:24:13 +0100
From: Jan Vanbrabant <[login to unmask email]>
Subject: Re: CICS/DB2 Accounting Question

It's OK, Max, thanks!

You put me on orbit to go and read the excellent (by the way) CICS-DB2
Guide:


*SC34-7011-01 CICS TS for z/OS V4R1 DB2 Guide*

Chapter10. Accounting and monitoring in a CICS DB2 environment
............139

Relating DB2 accounting records to CICS performance class records
.........155

What are the issues when matching DB2 accounting records and
CICS performance records? ... 156

Controlling the relationship between DB2 accounting records
and CICS performance class records ... 157

Using data in the DB2 accounting record to identify the
corresponding CICS performance classrecords .... 158

Strategies to match DB2 accounting records and CICS
performance class records and charge resources back to the user ...159



http://publib.boulder.ibm.com/infocenter/cicsts/v4r1/topic/com.ibm.cics.ts.doc/pdf/dfhtk_pdf.pdf



:-D



Thanks a lot!

jan


On Fri, Dec 3, 2010 at 11:37 AM, Max Scarpa <[login to unmask email]> wrote:

> Sent, hope you received it . It0s an old article, I think there are more
> recent versions but I've to dig more.
>
> Max
>
>
> ------------------------------
>
> [image: Independent, not-for-profit, User Run - the IDUG
> difference! ] < http://www.idug.org/ >
>
> The IDUG DB2-L Listserv is only part of your membership in IDUG. If you
> are
> not already an IDUG member, please register
> here. < http://www.idug.org/register >
>

_____________________________________________________________________
* IDUG North America * Anaheim, California * May 2-6 2011 *
http://IDUG.ORG/NA *
* Your only source for independent, unbiased, and trusted DB2 information.
*
** The best DB2 technical sessions in the world
** Independent, not-for-profit, User Run - the IDUG difference!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is
the home of IDUG's Listserv

------------------------------

Date: Fri, 3 Dec 2010 07:01:34 -0600
From: Daniel Luksetich <[login to unmask email]>
Subject: Re: 24 X 7 DB2 & replication server

This seems like a 20 year old recommendation and a way to sell some
software.



Regardless of platform DB2 should be able to handle a mixed workload. Given
proper application design that minimizes locking, minimizes SQL execution,
properly clusters data, and keeps keys and indexes under control, you can
run a mixed workload 24X7 without issue. I've seen this happen many times.



24X7 and high availability are a completely different issue than running
batch and online on the same machine. Depending upon your requirements it
may be appropriate to push data to a secondary site. Depending upon the
costs of maintaining the secondary site, you may find yourself replicating
data and operating non-core processes at the secondary site. True 24X7 also
requires customization of application and database objects.



You should hire a non-IBM consultant to give you a second opinion. There are
lots of good ones out there.



Or, just open your wallet. Lots of people do that too.



Cheers,

Dan



Daniel L Luksetich

IBM Information Champion

IBM Certified Database Administrator - DB2 10 for z/OS

IBM Certified System Administrator - DB2 9 for z/OS

IBM Certified Solutions Expert - DB2 Universal Database V7.1 Database
Administration for UNIX, Windows, and OS/2

IBM Certified Solutions Expert - DB2 UDB V7.1 Family Application Development

IBM Certified Advanced Technical Expert - DB2 Data Replication



Vice President of Global Database Operations

YL&A, Inc.

Database Performance Professionals

http://www.ylassoc.com

http://www.db2expert.com

http://www-01.ibm.com/software/data/champion/profiles/luksetich.html







From: IDUG DB2-L [mailto:[login to unmask email] On Behalf Of
[login to unmask email]
Sent: Monday, November 29, 2010 10:28 AM
To: [login to unmask email]
Subject: [SPAM] 24 X 7 DB2 & replication server



Hi all,

In order to achieve 24x7 and high availability, IBM recommend our shop to
run 2 DB2 subsystem, one for online and the other DB2 for batch, a DB2
replication server is used to replicate the log changed between this two DB2
subsystem.
Is there any shop use this approach? Any comment will be appreciated.

Thanks & regards

_____

< http://www.idug.org > Independent, not-for-profit, User Run - the IDUG
difference!

The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are
not already an IDUG member, please < http://www.idug.org/register > register
here.

No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.872 / Virus Database: 271.1.1/3285 - Release Date: 11/28/10
13:34:00


_____________________________________________________________________
* IDUG North America * Anaheim, California * May 2-6 2011 *
http://IDUG.ORG/NA *
* Your only source for independent, unbiased, and trusted DB2 information.
*
** The best DB2 technical sessions in the world
** Independent, not-for-profit, User Run - the IDUG difference!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is
the home of IDUG's Listserv

------------------------------

Date: Fri, 3 Dec 2010 08:14:46 -0500
From: Bill Gannon <[login to unmask email]>
Subject: Re: Creating the same database but??

Your best (cheapest) bet is probably DB2Look ....



db2look -d <DBname> -e -o <OutputFilename>





William B. Gannon

- IBM Certified Database Administrator

DB2 9 for Linux, Unix and Windows

- IBM Certified Solutions Expert

- IBM Certified Database Administrator

DB2 Universal Database V8.1 for zOS



________________________________

From: IDUG DB2-L [mailto:[login to unmask email] On Behalf Of Rasmussen, Steen
Sent: Monday, November 29, 2010 3:18 PM
To: [login to unmask email]
Subject: Re: [DB2-L] Creating the same database but??



Is this LUW or z/OS - and are you thinking about how to create the database
as well as all dependent objects with a different naming convention ?



Steen Rasmussen
CA Technologies
Sr Engineering Services Architect



From: IDUG DB2-L [mailto:[login to unmask email] On Behalf Of Ibrahim DEMIR
Sent: Monday, November 29, 2010 2:03 PM
To: [login to unmask email]
Subject: [DB2-L] Creating the same database but??



Hi All;

I have a simple question. What is the best way of creating the same database
but only change will be in codepage. All other configurations must be the
same.
By the way the data is not important for me. Because I have my insert
scripts .

Thanks .
-----
İbrahim DEMİR
twt: @ibrahimdemir
ff: @ibrahimdemir
http://www.ibrahimdemir.org

________________________________

Independent, not-for-profit, User Run - the IDUG difference!
< http://www.idug.org >

The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are
not already an IDUG member, please register here.
< http://www.idug.org/register >


________________________________

Independent, not-for-profit, User Run - the IDUG difference!
< http://www.idug.org >

The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are
not already an IDUG member, please register here.
< http://www.idug.org/register >


_____________________________________________________________________
* IDUG North America * Anaheim, California * May 2-6 2011 *
http://IDUG.ORG/NA *
* Your only source for independent, unbiased, and trusted DB2 information.
*
** The best DB2 technical sessions in the world
** Independent, not-for-profit, User Run - the IDUG difference!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is
the home of IDUG's Listserv

------------------------------

Date: Fri, 3 Dec 2010 07:50:29 -0600
From: "Reavill, Jay" <[login to unmask email]>
Subject: Re: AW: Service Units for a Dynamic Bind

Hi Walter,



Assuming you meant me (Jay)...



No, I wasn't saying that it is performed by the DDF address space, but that
is a good question. Is it? I was under the impression that it was being
performed by the SQL's distributed thread coming in and thereby under the
priority of its service class. If that's not the case then we need to take
a different look at it. We're just trying to make sure that the DDF threads
coming in have enough juice to get thru the dynamic bind (if needed) without
getting stalled. Some of the work is report type stuff which we want to
have a low priority, but need it to get throw any bind activity quickly.
It's a third party product so we don't have much, if any, control over the
SQL coming in.



Thanks,

Jay



------------------------------------------------------------------------

Jay Reavill

DBA

Fidelity National Information Services, Inc.

11601 Roosevelt Blvd., St. Petersburg, FL. 33716

Office: 727-227-2144 | Cell: 727-215-5794

[login to unmask email] <mailto:[login to unmask email]>

------------------------------------------------------------------------

________________________________

From: IDUG DB2-L [mailto:[login to unmask email] On Behalf Of Walter Janißen
Sent: Friday, December 03, 2010 5:03 AM
To: [login to unmask email]
Subject: [DB2-L] AW: Service Units for a Dynamic Bind



Ray



I am not sure, if I understand, what you were telling. Do you mean, that the
dynamic bind is performed by the DDF-address-space?



regards
Walter Janißen

ITERGO Informationstechnologie GmbH
Anwendungsentwicklung
Systeme Laufzeitarchitektur
Victoriaplatz 2
D-40198 Düsseldorf
[login to unmask email] <mailto:[login to unmask email]>

Vorsitzender des Aufsichtsrats: Jürgen Vetter
Geschäftsführung: Dr. Bettina Anders (Vorsitzende),
Ina Kirchhof, Dr. Christian Nymphius, Dr. Michael Regauer, Wolfgang Schön
Sitz: Düsseldorf, Handelsregister: Amtsgericht Düsseldorf, HRB 37996








________________________________


Von: IDUG DB2-L [mailto:[login to unmask email] Im Auftrag von Reavill, Jay
Gesendet: Mittwoch, 1. Dezember 2010 19:31
An: [login to unmask email]
Betreff: [DB2-L] Service Units for a Dynamic Bind

Anyone have a ROT on the amount of service units it takes to perform a
dynamic bind? I'm sure it fluctuates depending on the complexity of the
SQL, but we're trying to make sure that we have enough juice being allotted
to our period 1 WLM service classes for the distributed work coming in so
that they don't get "stuck" due to CPU constraints and end up holding locks
on system objects while in the middle of a dynamic bind. We also don't want
to thru too much juice their way because we don't want them to dominate
unnecessarily. We're just trying to avoid system level contention.



As always, Thanks!

Jay



------------------------------------------------------------------------

Jay Reavill

DBA

Fidelity National Information Services, Inc.

11601 Roosevelt Blvd., St. Petersburg, FL. 33716

Office: 727-227-2144 | Cell: 727-215-5794

[login to unmask email] <mailto:[login to unmask email]>

------------------------------------------------------------------------



_____________

The information contained in this message is proprietary and/or
confidential. If you are not the intended recipient, please: (i) delete the
message and all copies; (ii) do not disclose, distribute or use the message
in any manner; and (iii) notify the sender immediately. In addition, please
be aware that any message addressed to our domain is subject to archiving
and review by persons other than the intended recipient. Thank you.
_____________




________________________________


Independent, not-for-profit, User Run - the IDUG difference!
< http://www.idug.org >

The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are
not already an IDUG member, please register here.
< http://www.idug.org/register >


________________________________

Independent, not-for-profit, User Run - the IDUG difference!
< http://www.idug.org >

The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are
not already an IDUG member, please register here.
< http://www.idug.org/register >

_____________

The information contained in this message is proprietary and/or
confidential. If you are not the intended recipient, please: (i) delete the
message and all copies; (ii) do not disclose, distribute or use the message
in any manner; and (iii) notify the sender immediately. In addition, please
be aware that any message addressed to our domain is subject to archiving
and review by persons other than the intended recipient. Thank you.
_____________

_____________________________________________________________________
* IDUG North America * Anaheim, California * May 2-6 2011 *
http://IDUG.ORG/NA *
* Your only source for independent, unbiased, and trusted DB2 information.
*
** The best DB2 technical sessions in the world
** Independent, not-for-profit, User Run - the IDUG difference!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is
the home of IDUG's Listserv

------------------------------

Date: Fri, 3 Dec 2010 08:01:14 -0600
From: Daniel Luksetich <[login to unmask email]>
Subject: Re: AW: Service Units for a Dynamic Bind

This is a question for IBM so you should really open an ETR. If you can’t do
that, and if memory serves me correctly (it has been several years since I
investigated this), I believe dynamic binds get a higher priority. I could
be wrong so double check with IBM or assume that your priority settings will
not affect any prepare/bind.



Cheers,

Dan



From: IDUG DB2-L [mailto:[login to unmask email] On Behalf Of Reavill, Jay
Sent: Friday, December 03, 2010 7:50 AM
To: [login to unmask email]
Subject: [SPAM] Re: AW: Service Units for a Dynamic Bind



Hi Walter,



Assuming you meant me (Jay)…



No, I wasn’t saying that it is performed by the DDF address space, but that
is a good question. Is it? I was under the impression that it was being
performed by the SQL’s distributed thread coming in and thereby under the
priority of its service class. If that’s not the case then we need to take
a different look at it. We’re just trying to make sure that the DDF threads
coming in have enough juice to get thru the dynamic bind (if needed) without
getting stalled. Some of the work is report type stuff which we want to
have a low priority, but need it to get throw any bind activity quickly.
It’s a third party product so we don’t have much, if any, control over the
SQL coming in.



Thanks,

Jay



------------------------------------------------------------------------

Jay Reavill

DBA

Fidelity National Information Services, Inc.

11601 Roosevelt Blvd., St. Petersburg, FL. 33716

Office: 727-227-2144 | Cell: 727-215-5794

[login to unmask email] <mailto:[login to unmask email]>

------------------------------------------------------------------------

_____

From: IDUG DB2-L [mailto:[login to unmask email] On Behalf Of Walter Janißen
Sent: Friday, December 03, 2010 5:03 AM
To: [login to unmask email]
Subject: [DB2-L] AW: Service Units for a Dynamic Bind



Ray



I am not sure, if I understand, what you were telling. Do you mean, that the
dynamic bind is performed by the DDF-address-space?



regards
Walter Janißen

ITERGO Informationstechnologie GmbH
Anwendungsentwicklung
Systeme Laufzeitarchitektur
Victoriaplatz 2
D-40198 Düsseldorf
<mailto:[login to unmask email]> [login to unmask email]

Vorsitzender des Aufsichtsrats: Jürgen Vetter
Geschäftsführung: Dr. Bettina Anders (Vorsitzende),
Ina Kirchhof, Dr. Christian Nymphius, Dr. Michael Regauer, Wolfgang Schön
Sitz: Düsseldorf, Handelsregister: Amtsgericht Düsseldorf, HRB 37996








_____


Von: IDUG DB2-L [mailto:[login to unmask email] Im Auftrag von Reavill, Jay
Gesendet: Mittwoch, 1. Dezember 2010 19:31
An: [login to unmask email]
Betreff: [DB2-L] Service Units for a Dynamic Bind

Anyone have a ROT on the amount of service units it takes to perform a
dynamic bind? I’m sure it fluctuates depending on the complexity of the
SQL, but we’re trying to make sure that we have enough juice being allotted
to our period 1 WLM service classes for the distributed work coming in so
that they don’t get “stuck” due to CPU constraints and end up holding locks
on system objects while in the middle of a dynamic bind. We also don’t want
to thru too much juice their way because we don’t want them to dominate
unnecessarily. We’re just trying to avoid system level contention.



As always, Thanks!

Jay



------------------------------------------------------------------------

Jay Reavill

DBA

Fidelity National Information Services, Inc.

11601 Roosevelt Blvd., St. Petersburg, FL. 33716

Office: 727-227-2144 | Cell: 727-215-5794

[login to unmask email] <mailto:[login to unmask email]>

------------------------------------------------------------------------



_____________

The information contained in this message is proprietary and/or
confidential. If you are not the intended recipient, please: (i) delete the
message and all copies; (ii) do not disclose, distribute or use the message
in any manner; and (iii) notify the sender immediately. In addition, please
be aware that any message addressed to our domain is subject to archiving
and review by persons other than the intended recipient. Thank you.
_____________



_____

< http://www.idug.org > Independent, not-for-profit, User Run - the IDUG
difference!

The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are
not already an IDUG member, please < http://www.idug.org/register > register
here.

_____________

The information contained in this message is proprietary and/or
confidential. If you are not the intended recipient, please: (i) delete the
message and all copies; (ii) do not disclose, distribute or use the message
in any manner; and (iii) notify the sender immediately. In addition, please
be aware that any message addressed to our domain is subject to archiving
and review by persons other than the intended recipient. Thank you.
_____________



_____

< http://www.idug.org > Independent, not-for-profit, User Run - the IDUG
difference!

The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are
not already an IDUG member, please < http://www.idug.org/register > register
here.



_____

< http://www.idug.org > Independent, not-for-profit, User Run - the IDUG
difference!

The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are
not already an IDUG member, please < http://www.idug.org/register > register
here.

No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.872 / Virus Database: 271.1.1/3289 - Release Date: 12/01/10
01:34:00


_____________________________________________________________________
* IDUG North America * Anaheim, California * May 2-6 2011 *
http://IDUG.ORG/NA *
* Your only source for independent, unbiased, and trusted DB2 information.
*
** The best DB2 technical sessions in the world
** Independent, not-for-profit, User Run - the IDUG difference!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is
the home of IDUG's Listserv

------------------------------

Date: Fri, 3 Dec 2010 09:01:41 -0600
From: "Vaughan, Mike" <[login to unmask email]>
Subject: Re: AW: Service Units for a Dynamic Bind

Just for clarification, when you say "Dynamic Bind" do you really mean
the PREPARE? If so, then you are correct that the complexity of the SQL
greatly impacts the service units required to complete the PREPARE.
Specifically what I have found in the past is the number of tables being
joined has a huge impact. A few years ago I ran some traces to determine
how the number of joins impacts PREPARE times and found that the cputime
increased exponentially once you reached around 12 tables in the join. This
test was a worst-case scenario of joining the same table to itself on the
same column x-times, so the number of possible join permutations was huge.
"Real world" SQL likely wouldn't see the same impact and I know there are
also some zparms to tame this down a little (and I believe the default for
those under DB2 9 eliminates, or at least greatly reduces the "exponential"
impact I mentioned). Unfortunately trying to give a ROT for PREPARE time
overhead is very difficult due to the wide variance in sql. What I have
done in the past is just try to setup an isolated test run of the app in
question with a trace running and pick out the PREPARE times. You also
probably need to take dynamic caching into account here if you are looking
at PREPARE overhead.
Regarding the WLM service classes, occasionally we do experience the
exact impact you mention -- a process does not have enough "juice" to
complete the PREPARE in the time allocated for period-1, and it has degraded
before it can even start it's "real" work, and on very busy days they do
occasionally get "stuck" for an extended period of time.

Thanks,
Mike.
________________________________
From: IDUG DB2-L [mailto:[login to unmask email] On Behalf Of Daniel Luksetich
Sent: Friday, December 03, 2010 8:01 AM
To: [login to unmask email]
Subject: Re: [DB2-L] AW: Service Units for a Dynamic Bind

This is a question for IBM so you should really open an ETR. If you can't do
that, and if memory serves me correctly (it has been several years since I
investigated this), I believe dynamic binds get a higher priority. I could
be wrong so double check with IBM or assume that your priority settings will
not affect any prepare/bind.

Cheers,
Dan

From: IDUG DB2-L [mailto:[login to unmask email] On Behalf Of Reavill, Jay
Sent: Friday, December 03, 2010 7:50 AM
To: [login to unmask email]
Subject: [SPAM] Re: AW: Service Units for a Dynamic Bind

Hi Walter,

Assuming you meant me (Jay)...

No, I wasn't saying that it is performed by the DDF address space, but that
is a good question. Is it? I was under the impression that it was being
performed by the SQL's distributed thread coming in and thereby under the
priority of its service class. If that's not the case then we need to take
a different look at it. We're just trying to make sure that the DDF threads
coming in have enough juice to get thru the dynamic bind (if needed) without
getting stalled. Some of the work is report type stuff which we want to
have a low priority, but need it to get throw any bind activity quickly.
It's a third party product so we don't have much, if any, control over the
SQL coming in.

Thanks,
Jay

------------------------------------------------------------------------
Jay Reavill
DBA
Fidelity National Information Services, Inc.
11601 Roosevelt Blvd., St. Petersburg, FL. 33716
Office: 727-227-2144 | Cell: 727-215-5794
[login to unmask email]<mailto:[login to unmask email]>
------------------------------------------------------------------------
________________________________
From: IDUG DB2-L [mailto:[login to unmask email] On Behalf Of Walter Janißen
Sent: Friday, December 03, 2010 5:03 AM
To: [login to unmask email]
Subject: [DB2-L] AW: Service Units for a Dynamic Bind

Ray

I am not sure, if I understand, what you were telling. Do you mean, that the
dynamic bind is performed by the DDF-address-space?


regards
Walter Janißen

ITERGO Informationstechnologie GmbH
Anwendungsentwicklung
Systeme Laufzeitarchitektur
Victoriaplatz 2
D-40198 Düsseldorf
[login to unmask email]<mailto:[login to unmask email]>

Vorsitzender des Aufsichtsrats: Jürgen Vetter
Geschäftsführung: Dr. Bettina Anders (Vorsitzende),
Ina Kirchhof, Dr. Christian Nymphius, Dr. Michael Regauer, Wolfgang Schön
Sitz: Düsseldorf, Handelsregister: Amtsgericht Düsseldorf, HRB 37996



________________________________
Von: IDUG DB2-L [mailto:[login to unmask email] Im Auftrag von Reavill, Jay
Gesendet: Mittwoch, 1. Dezember 2010 19:31
An: [login to unmask email]
Betreff: [DB2-L] Service Units for a Dynamic Bind
Anyone have a ROT on the amount of service units it takes to perform a
dynamic bind? I'm sure it fluctuates depending on the complexity of the
SQL, but we're trying to make sure that we have enough juice being allotted
to our period 1 WLM service classes for the distributed work coming in so
that they don't get "stuck" due to CPU constraints and end up holding locks
on system objects while in the middle of a dynamic bind. We also don't want
to thru too much juice their way because we don't want them to dominate
unnecessarily. We're just trying to avoid system level contention.

As always, Thanks!
Jay

------------------------------------------------------------------------
Jay Reavill
DBA
Fidelity National Information Services, Inc.
11601 Roosevelt Blvd., St. Petersburg, FL. 33716
Office: 727-227-2144 | Cell: 727-215-5794
[login to unmask email]<mailto:[login to unmask email]>
------------------------------------------------------------------------

</pre><br>-----Message Disclaimer-----<br><br>This e-mail message is
intended only for the use of the individual or entity to which it is
addressed, and may contain information that is privileged, confidential and
exempt from disclosure under applicable law. If you are not the intended
recipient, any dissemination, distribution or copying of this communication
is strictly prohibited. If you have received this communication in error,
please notify us immediately by reply email to [login to unmask email] and
delete or destroy all copies of the original message and attachments
thereto. Email sent to or from the Principal Financial Group or any of its
member companies may be retained as required by law or regulation.<br><br>
Nothing in this message is intended to constitute an Electronic signature
for purposes of the Uniform Electronic Transactions Act (UETA) or the
Electronic Signatures in Global and National Commerce Act
("E-Sign") unless a specific statement to the contrary is included
in this message.<br><br>While this communication may be used to promote or
market a transaction or an idea that is discussed in the publication, it is
intended to provide general information about the subject matter covered and
is provided with the understanding that The Principal is not rendering
legal, accounting, or tax advice. It is not a marketed opinion and may not
be used to avoid penalties under the Internal Revenue Code. You should
consult with appropriate counsel or other advisors on all matters pertaining
to legal, tax, or accounting obligations and requirements.<br><pre>

_____________________________________________________________________
* IDUG North America * Anaheim, California * May 2-6 2011 *
http://IDUG.ORG/NA *
* Your only source for independent, unbiased, and trusted DB2 information.
*
** The best DB2 technical sessions in the world
** Independent, not-for-profit, User Run - the IDUG difference!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is
the home of IDUG's Listserv

------------------------------

Date: Fri, 3 Dec 2010 09:13:30 -0600
From: "Reavill, Jay" <[login to unmask email]>
Subject: Re: AW: Service Units for a Dynamic Bind

Thanks Mike, you've hit exactly what I'm referring to. Sounds like we need
to run some traces and go from there.



Thanks again,

Jay



------------------------------------------------------------------------

Jay Reavill

DBA

Fidelity National Information Services, Inc.

11601 Roosevelt Blvd., St. Petersburg, FL. 33716

Office: 727-227-2144 | Cell: 727-215-5794

[login to unmask email] <mailto:[login to unmask email]>

------------------------------------------------------------------------

________________________________

From: IDUG DB2-L [mailto:[login to unmask email] On Behalf Of Vaughan, Mike
Sent: Friday, December 03, 2010 10:02 AM
To: [login to unmask email]
Subject: Re: [DB2-L] AW: Service Units for a Dynamic Bind



Just for clarification, when you say "Dynamic Bind" do you really mean
the PREPARE? If so, then you are correct that the complexity of the SQL
greatly impacts the service units required to complete the PREPARE.
Specifically what I have found in the past is the number of tables being
joined has a huge impact. A few years ago I ran some traces to determine
how the number of joins impacts PREPARE times and found that the cputime
increased exponentially once you reached around 12 tables in the join. This
test was a worst-case scenario of joining the same table to itself on the
same column x-times, so the number of possible join permutations was huge.
"Real world" SQL likely wouldn't see the same impact and I know there are
also some zparms to tame this down a little (and I believe the default for
those under DB2 9 eliminates, or at least greatly reduces the "exponential"
impact I mentioned). Unfortunately trying to give a ROT for PREPARE time
overhead is very difficult due to the wide variance in sql. What I have
done in the past is just try to setup an isolated test run of the app in
question with a trace running and pick out the PREPARE times. You also
probably need to take dynamic caching into account here if you are looking
at PREPARE overhead.

Regarding the WLM service classes, occasionally we do experience the
exact impact you mention -- a process does not have enough "juice" to
complete the PREPARE in the time allocated for period-1, and it has degraded
before it can even start it's "real" work, and on very busy days they do
occasionally get "stuck" for an extended period of time.



Thanks,

Mike.

________________________________

From: IDUG DB2-L [mailto:[login to unmask email] On Behalf Of Daniel Luksetich
Sent: Friday, December 03, 2010 8:01 AM
To: [login to unmask email]
Subject: Re: [DB2-L] AW: Service Units for a Dynamic Bind

This is a question for IBM so you should really open an ETR. If you can't do
that, and if memory serves me correctly (it has been several years since I
investigated this), I believe dynamic binds get a higher priority. I could
be wrong so double check with IBM or assume that your priority settings will
not affect any prepare/bind.



Cheers,

Dan



From: IDUG DB2-L [mailto:[login to unmask email] On Behalf Of Reavill, Jay
Sent: Friday, December 03, 2010 7:50 AM
To: [login to unmask email]
Subject: [SPAM] Re: AW: Service Units for a Dynamic Bind



Hi Walter,



Assuming you meant me (Jay)...



No, I wasn't saying that it is performed by the DDF address space, but that
is a good question. Is it? I was under the impression that it was being
performed by the SQL's distributed thread coming in and thereby under the
priority of its service class. If that's not the case then we need to take
a different look at it. We're just trying to make sure that the DDF threads
coming in have enough juice to get thru the dynamic bind (if needed) without
getting stalled. Some of the work is report type stuff which we want to
have a low priority, but need it to get throw any bind activity quickly.
It's a third party product so we don't have much, if any, control over the
SQL coming in.



Thanks,

Jay



------------------------------------------------------------------------

Jay Reavill

DBA

Fidelity National Information Services, Inc.

11601 Roosevelt Blvd., St. Petersburg, FL. 33716

Office: 727-227-2144 | Cell: 727-215-5794

[login to unmask email] <mailto:[login to unmask email]>

------------------------------------------------------------------------

________________________________

From: IDUG DB2-L [mailto:[login to unmask email] On Behalf Of Walter Janißen
Sent: Friday, December 03, 2010 5:03 AM
To: [login to unmask email]
Subject: [DB2-L] AW: Service Units for a Dynamic Bind



Ray



I am not sure, if I understand, what you were telling. Do you mean, that the
dynamic bind is performed by the DDF-address-space?



regards
Walter Janißen

ITERGO Informationstechnologie GmbH
Anwendungsentwicklung
Systeme Laufzeitarchitektur
Victoriaplatz 2
D-40198 Düsseldorf
[login to unmask email] <mailto:[login to unmask email]>

Vorsitzender des Aufsichtsrats: Jürgen Vetter
Geschäftsführung: Dr. Bettina Anders (Vorsitzende),
Ina Kirchhof, Dr. Christian Nymphius, Dr. Michael Regauer, Wolfgang Schön
Sitz: Düsseldorf, Handelsregister: Amtsgericht Düsseldorf, HRB 37996








________________________________


Von: IDUG DB2-L [mailto:[login to unmask email] Im Auftrag von Reavill, Jay
Gesendet: Mittwoch, 1. Dezember 2010 19:31
An: [login to unmask email]
Betreff: [DB2-L] Service Units for a Dynamic Bind

Anyone have a ROT on the amount of service units it takes to perform a
dynamic bind? I'm sure it fluctuates depending on the complexity of the
SQL, but we're trying to make sure that we have enough juice being allotted
to our period 1 WLM service classes for the distributed work coming in so
that they don't get "stuck" due to CPU constraints and end up holding locks
on system objects while in the middle of a dynamic bind. We also don't want
to thru too much juice their way because we don't want them to dominate
unnecessarily. We're just trying to avoid system level contention.



As always, Thanks!

Jay



------------------------------------------------------------------------

Jay Reavill

DBA

Fidelity National Information Services, Inc.

11601 Roosevelt Blvd., St. Petersburg, FL. 33716

Office: 727-227-2144 | Cell: 727-215-5794

[login to unmask email] <mailto:[login to unmask email]>

------------------------------------------------------------------------




-----Message Disclaimer-----

This e-mail message is intended only for the use of the individual or entity
to which it is addressed, and may contain information that is privileged,
confidential and exempt from disclosure under applicable law. If you are not
the intended recipient, any dissemination, distribution or copying of this
communication is strictly prohibited. If you have received this
communication in error, please notify us immediately by reply email to
[login to unmask email] and delete or destroy all copies of the original
message and attachments thereto. Email sent to or from the Principal
Financial Group or any of its member companies may be retained as required
by law or regulation.

Nothing in this message is intended to constitute an Electronic signature
for purposes of the Uniform Electronic Transactions Act (UETA) or the
Electronic Signatures in Global and National Commerce Act ("E-Sign") unless
a specific statement to the contrary is included in this message.

While this communication may be used to promote or market a transaction or
an idea that is discussed in the publication, it is intended to provide
general information about the subject matter covered and is provided with
the understanding that The Principal is not rendering legal, accounting, or
tax advice. It is not a marketed opinion and may not be used to avoid
penalties under the Internal Revenue Code. You should consult with
appropriate counsel or other advisors on all matters pertaining to legal,
tax, or accounting obligations and requirements.



________________________________


Independent, not-for-profit, User Run - the IDUG difference!
< http://www.idug.org >

The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are
not already an IDUG member, please register here.
< http://www.idug.org/register >

_____________

The information contained in this message is proprietary and/or
confidential. If you are not the intended recipient, please: (i) delete the
message and all copies; (ii) do not disclose, distribute or use the message
in any manner; and (iii) notify the sender immediately. In addition, please
be aware that any message addressed to our domain is subject to archiving
and review by persons other than the intended recipient. Thank you.
_____________

_____________________________________________________________________
* IDUG North America * Anaheim, California * May 2-6 2011 *
http://IDUG.ORG/NA *
* Your only source for independent, unbiased, and trusted DB2 information.
*
** The best DB2 technical sessions in the world
** Independent, not-for-profit, User Run - the IDUG difference!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is
the home of IDUG's Listserv

------------------------------

Date: Fri, 3 Dec 2010 08:14:04 -0800
From: Myron Miller <[login to unmask email]>
Subject: Re: AW: Service Units for a Dynamic Bind

But Jay,
Understand that the SQL and dynamic BIND are both executed at the same
priority. You can't specify one priority for the bind and another for the
sql.
It doesn't work that way.

What ever priority you have for the application, set by WLM for the DDF
address
functions (and you can specify in WLM different priorities for different
authids) is what the bind runs at. So if an app has a very low priority,
it's
dynamic bind will run at that priority and get whatever cycles everything
for
that app gets.

Myron



________________________________
From: "Reavill, Jay" <[login to unmask email]>
To: [login to unmask email]
Sent: Fri, December 3, 2010 8:50:29 AM
Subject: Re: [DB2-L] AW: Service Units for a Dynamic Bind


Hi Walter,

Assuming you meant me (Jay)…

No, I wasn’t saying that it is performed by the DDF address space, but that
is a
good question. Is it? I was under the impression that it was being
performed
by the SQL’s distributed thread coming in and thereby under the priority of
its
service class. If that’s not the case then we need to take a different look
at
it. We’re just trying to make sure that the DDF threads coming in have
enough
juice to get thru the dynamic bind (if needed) without getting stalled.
Some of
the work is report type stuff which we want to have a low priority, but need
it
to get throw any bind activity quickly. It’s a third party product so we
don’t
have much, if any, control over the SQL coming in.

Thanks,
Jay

------------------------------------------------------------------------
Jay Reavill
DBA
Fidelity National Information Services, Inc.
11601 Roosevelt Blvd., St. Petersburg, FL. 33716
Office: 727-227-2144 | Cell: 727-215-5794
[login to unmask email]
------------------------------------------------------------------------

________________________________

From:IDUG DB2-L [mailto:[login to unmask email] On Behalf Of Walter Janißen
Sent: Friday, December 03, 2010 5:03 AM
To: [login to unmask email]
Subject: [DB2-L] AW: Service Units for a Dynamic Bind

Ray

I am not sure, if I understand, what you were telling. Do you mean, that the
dynamic bind is performed by the DDF-address-space?

regards
Walter Janißen

ITERGO Informationstechnologie GmbH
Anwendungsentwicklung
Systeme Laufzeitarchitektur
Victoriaplatz 2
D-40198 Düsseldorf
[login to unmask email]

Vorsitzender des Aufsichtsrats: Jürgen Vetter
Geschäftsführung: Dr. Bettina Anders (Vorsitzende),
Ina Kirchhof, Dr. Christian Nymphius, Dr. Michael Regauer, Wolfgang Schön
Sitz: Düsseldorf, Handelsregister: Amtsgericht Düsseldorf, HRB 37996



>
________________________________

>Von:IDUG DB2-L [mailto:[login to unmask email] Im Auftrag von Reavill, Jay
>Gesendet: Mittwoch, 1. Dezember 2010 19:31
>An: [login to unmask email]
>Betreff: [DB2-L] Service Units for a Dynamic Bind
>Anyone have a ROT on the amount of service units it takes to perform a
>dynamic
>bind? I’m sure it fluctuates depending on the complexity of the SQL, but
>we’re
>trying to make sure that we have enough juice being allotted to our period
>1 WLM
>service classes for the distributed work coming in so that they don’t get
>“stuck” due to CPU constraints and end up holding locks on system objects
>while
>in the middle of a dynamic bind. We also don’t want to thru too much juice
>their way because we don’t want them to dominate unnecessarily. We’re just
>trying to avoid system level contention.
>
>As always, Thanks!
>Jay
>
>------------------------------------------------------------------------
>Jay Reavill
>DBA
>Fidelity National Information Services, Inc.
>11601 Roosevelt Blvd., St. Petersburg, FL. 33716
>Office: 727-227-2144 | Cell: 727-215-5794
>[login to unmask email]
>------------------------------------------------------------------------
>
>_____________
>
>The information contained in this message is proprietary and/or
>confidential. If
>you are not the intended recipient, please: (i) delete the message and all
>copies; (ii) do not disclose, distribute or use the message in any manner;
>and
>(iii) notify the sender immediately. In addition, please be aware that any
>message addressed to our domain is subject to archiving and review by
>persons
>other than the intended recipient. Thank you.
>_____________
>
>
________________________________

>The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are
>not
>already an IDUG member, please register here.
>
_____________

The information contained in this message is proprietary and/or
confidential. If
you are not the intended recipient, please: (i) delete the message and all
copies; (ii) do not disclose, distribute or use the message in any manner;
and
(iii) notify the sender immediately. In addition, please be aware that any
message addressed to our domain is subject to archiving and review by
persons
other than the intended recipient. Thank you.
_____________

________________________________

The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are
not
already an IDUG member, please register here.

________________________________

The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are
not
already an IDUG member, please register here.


_________________________________________________________