EDM POOL FULL condition after migrating to V8 NFM : some related questions

PAUL WALTERS

EDM POOL FULL condition after migrating to V8 NFM : some related questions
We are in the same boat with the release(deallocate) as compared to release(commit).

We are CICS/DB2 V8 datasharing shop with protected threads and all of our CICS programs are bound with release(deallocate) and we have a large EDM pool that can spike if there is a large influx of db2 threads.

How are others managing this conversion from release(deallocate) to release(commit) -
Are you just changing the default so all cics packages are bound with release(commit)?
Are you trying to bind your heavy hitting cics programs with deallocate and everyone else with commit. This option maybe the best but how do you manage changes in the list and or new programs that move into production and become heavy hitting. We are looking for an automated option - if we let the developers decided they will likely make the wrong choice.

All of our code migrations happen through Endevor so that is a controlled process. We also do use Avoid bind to avoid binding if the SQL has not changed.

Thanks




From: DB2 Data Base Discussion List [mailto:[login to unmask email] On Behalf Of Robert Catterall
Sent: Thursday, January 08, 2009 9:47 AM
To: Walters, Paul; DB2 Database Discussion list at IDUG
Subject: Re: [DB2-L] EDM POOL FULL condition after migrating to V8 NFM : more data

Renzo,

Is your DB2 workload (during the "EDM pool full" times) primarily comprised of CICS-DB2 transactions? If so, are many of the associated DB2 packages bound with RELEASE(DEALLOCATE)? Are you using any protected CICS-DB2 threads (specified via PROTECTNUM in CICS RDO DB2ENTRY resource definitions)?

Historically, a lot of DB2 for z/OS data sharing users went with RELEASE(DEALLOCATE) for package bind in order to reduce tablespace lock propagation to the lock structure. In CICS-DB2 environments, tablespace lock propagation could be further reduced through the use of CICS protected entry threads. People were interested in reducing tablespace lock propagation because such requests often resulted in what's called XES contention - something that increased data sharing overhead. An unfortunate side-effect of RELEASE(DEALLOCATE) - especially when protected threads were also used - was an increase (sometimes quite substantial) in the usage of EDM pool space for sections of in-use packages (the "PT" part of the pool) - this because a package bound with RELEASE(DEALLOCATE) is considered to be "in-use" until the associated thread is deallocated (as opposed to being released at SYNCPOINT in the case of a CICS-DB2 tran). In some cases, even minor fluctuations in the CICS-DB2 transaction workload can lead to significant chnages in the rate of CICS-DB2 thread reuse, and that (when RELEASE(DEALLOCATE) is the package bind option) can lead to dramatic shifts in "in-use" versus "stealable" PT-related EDM pool pages.

The good news with respect to DB2 V8: due to a new global locking protocol, RELEASE(DEALLOCATE) is no longer needed to reduce the incidence of the type of global lock contention known as XES contention (I wrote about this in a blog entry last summer: http://www.catterallconsulting.com/2008/08/some-interesting-db2-for-zos-data.html). So, if you have a fair number of CICS-DB2 program packages bound with RELEASE(DEALLOCATE), and if that bind specification decision was made so as to reduce data sharing lock contention, consider changing the bind specification to RELEASE(COMMIT). In a DB2 V8 system you won't pay a global lock contention penalty for doing this, thanks to the afrementioned global locking protocol enhancement (known as "locking protocol 2," as I recall).

This may or may not explain what you are seeing. Something for you to consider and investigate.

Robert
On Thu, Jan 8, 2009 at 2:50 AM, Renzo razzetti <[login to unmask email]<mailto:[login to unmask email]>> wrote:
Hello,

I m adding more data in my question to see whether there is someone in the list can help me.
Following is the statistic from 1 minute interval. The EDM Pool is always around 40% used, but suddenly the PAGES of PT increase almost to 97% of the EDM Pool
I want to find the root cause of the problem, to avoid happen other time. I'm already checked the number of transaction in CICS and the number of thread in DB2 and they are not increase.

Could be this a bug in the EDM pool DB2 v8 ?

I will appreciate any suggestion to further analysis this problem.

RR


EDM POOL DP21

16:20

16:21

16:22

16:21



16:21

16:22

16:23

16:27

Elapsed time

1

1

1

6

PAGES IN EDM POOL (BELOW)

37500

37500

37500

37500

HELD BY CT

176

290.42

588

234.67

HELD BY PT

4936

13113.24

34380

8780.87

HELD BY SKCT

9

8.17

6

10.17

HELD BY SKPT

11415

8716.93

1700

7322.49

FREE PAGES

20964

15371.24

826

21151.81

% PAGES IN USE

44.1

59.01

97.8

43.6

% NON STEAL. PAGES IN USE

13.63

35.74

93.25

24.04

FAILS DUE TO POOL FULL

0

0

0

66

































































On Sun, Jan 4, 2009 at 10:43 AM, Renzo razzetti <[login to unmask email]<mailto:[login to unmask email]>> wrote:
>
> hello everybody !
>
> I'm running DB2 V8 NFM, Cobol LOCAL applications in datasharing enviorment.
> Not dynamic application are running, not distributed application is running, not storage procedure is running.
>
>
>
> I have received this error in production. 66 times in the 1 second interval. And the application canceled with RC -904 resource unavailable.
>
> 16.22.44 STC28433 DSNT500I -DP21 DSNGEPLC RESOURCE UNAVAILABLE 004
> 004 REASON 00C90089
> 004 TYPE 00000600
> 004 NAME EDM POOL SPACE
> ..................................
> 16.22.45 STC28433 DSNT500I -DP21 DSNGEPLC RESOURCE UNAVAILABLE 013
> 013 REASON 00C90089
> 013 TYPE 00000600
>
>
> If we look in the statistic report the EDM Pool for 15 interval during 16:15 to 16:30, we can see only the 40% of the pages are in use. It looks the EDM Pool is not full.
> Can any help to understand what is the problem ? How I can find the problem ?
> Thank you.
>
>
> EDM POOL QUANTITY /SECOND /THREAD /COMMIT
> --------------------------- -------- ------- ------- -------
> PAGES IN EDM POOL (BELOW) 37500.00 N/A N/A N/A
> HELD BY CT 208.86 N/A N/A N/A
> HELD BY PT 6682.08 N/A N/A N/A
> HELD BY SKCT 9.79 N/A N/A N/A
> HELD BY SKPT 9193.57 N/A N/A N/A
> FREE PAGES 21405.71 N/A N/A N/A
> % PAGES IN USE 42.92 N/A N/A N/A
> % NON STEAL. PAGES IN USE 18.38 N/A N/A N/A
> FAILS DUE TO POOL FULL 66.00 0.08 0.00 0.00
>
> PAGES IN DBD POOL (ABOVE) 20000.00 N/A N/A N/A
> HELD BY DBD 7632.00 N/A N/A N/A
> FREE PAGES 12368.00 N/A N/A N/A
> FAILS DUE TO DBD POOL FULL 0.00 0.00 0.00 0.00
>
> PAGES IN STMT POOL (ABOVE) 20000.00 N/A N/A N/A
> HELD BY STATEMENTS 18916.21 N/A N/A N/A
> FREE PAGES 1083.79 N/A N/A N/A
> FAILS DUE TO STMT POOL FULL 0.00 0.00 0.00 0.00
>
> DBD REQUESTS 70916.00 83.29 1.01 0.38
> DBD NOT FOUND 000 0.00 0.00 0.00
> DBD HIT RATIO (%) 100.00 N/A N/A N/A
> CT REQUESTS 70178.00 82.42 1.00 0.38
> CT NOT FOUND 1100 0.01 0.00 0.00
> CT HIT RATIO (%) 99.98 N/A N/A N/A
> PT REQUESTS 3385.0K 3975.56 48.22 18.18
> PT NOT FOUND 3592.00 4.22 0.05 0.02
> PT HIT RATIO (%) 99.89 N/A N/A N/A
>
> PKG SEARCH NOT FOUND 4018.8K 4719.88 57.25 21.58
> PKG SEARCH NOT FOUND INSERT 3040.00 3.57 0.04 0.02
> PKG SEARCH NOT FOUND DELETE 3041.00 3.57 004 0.02
>
>

________________________________

IDUG 2009 - Australasia * 18-20 March * Melbourne, Australia < http://idug.org/lsAU >

IDUG.org <http://www.idug.org> was recently updated requiring members to use a new password. You should have gotten an e-mail with the temporary password assigned to your account. Please log in and update your member profile. If you are not already an IDUG.org member, please register here.< http://www.idug.org/component/juser/register.html >



--
Robert Catterall
Catterall Consulting
www.catterallconsulting.com < http://www.catterallconsulting.com >
________________________________

IDUG 2009 - Australasia * 18-20 March * Melbourne, Australia < http://idug.org/lsAU >

IDUG.org <http://www.idug.org> was recently updated requiring members to use a new password. You should have gotten an e-mail with the temporary password assigned to your account. Please log in and update your member profile. If you are not already an IDUG.org member, please register here.< http://www.idug.org/component/juser/register.html >

This E-Mail has been scanned for viruses.


______________________________________________________________________

* IDUG 2009 Rome, Italy * 5-9 October * http://IDUG.ORG/Events *
______________________________________________________________________



IDUG.org was recently updated requiring members to use a new password. You should have gotten an e-mail with the temporary password assigned to your account. Please log in and update your member profile. If you are not already an IDUG.org member, please register at http://www.idug.org/component/juser/register.html