To resolve a situation that existed when a distributed client used a package bound with KEEPDYNAMIC(YES) that could potentially remain active with the connection for long periods of time, an enhancement referred to as “KEEPDYNAMIC DBAT refresh” was introduced at the end of 2009. Prior to this enhancement, KEEPDYNAMIC(YES) could allow a thread’s storage footprint to continually increase, sometimes resulting in the fragmentation of the DBM1 address space’s storage. This situation could eventually lead to application failures due to storage shortages. Not using KEEPDYNAMIC(YES) wasn’t often a viable option or a solution. The entire reason for KEEPDYNAMIC(YES) was to keep prepared statements active across commits, eliminating the need to go through the prepare process potentially multiple times, thus reducing overhead. Of course, because the statement is kept active, the thread is never returned to the pool, preventing it from being eligible for timeout.

If KEEPDYNAMIC DBAT refresh is active (defined as the only thing keeping the connection active and preventing the DBAT from being pooled), DDF can terminate a DBAT and connection if it has been used for more than one hour or has been idle for more than 20 minutes. There are a few other things that must be in effect for all this to happen. For example, CMTSTAT=INACTIVE must be in effect, client must support Sysplex Workload balancing and/or Seamless Failover plus a few other things that are detailed in APAR PK69339 along with examples of problematic situations that KEEPDYNAMIC DBAT refresh may help resolve.

Two reason codes also come with the other changes in support of KEEPDYNAMIC refresh. They have been added to message DSNL027I for a connection/thread termination when KEEPDYNAIMC refresh is enabled:

• 00D3003E: A connection/thread has been used for more than one hour.
• 00D3003F: A connection/thread has been idle for more than 20 minutes.

Connection/thread termination won’t occur if the connection/thread is actively processing a transaction or holding a resource past a commit for the two aforementioned conditions. DSNL027I also won’t be issued more than once in a five-minute internal if issued from the same client IP address. 

There’s considerably more detail about these two codes in the February 2013 and later release of the DB2 10 Codes (GC19-2971), or the October 2013 or later release of the DB2 11 Codes (GC19-4053) product publications.

Member Health Reduction

Ever since z/OS 1.8, every server has had a health value associated with it that’s passed to WLM. A value of 100 (representing a percentage) represents that all things for that server are copasetic. On the low end, a value of 0 (percent) means the server is probably non-functional. Based on this health value, WLM can make a more informed, and hopefully more accurate, routing decision. APAR PM43293 adjusted DB2’s DDF health value, reporting it to WLM immediately when the number of connections exceeds a percentage of the CONDBAT threshold. The DB2 health value is reduced to 50 percent of the current health value when the number of connections is at 80 percent of CONDBAT; 25 percent of the current health value is only valid when the number of connections exceeds 90 percent of CONDBAT. Message DSNL074I is also issued to inform that 80 or 90 percent of CONDBAT has been reached. Message DSNL075I is issued when the number of connections drops below 80 or 90 percent of CONDBAT. The DB2 health value is increased to 50 or 100 percent of the original health value and reported back to WLM again.     

Note: The changes to the DB2 health value and the DB2 messaging are only available in a data sharing environment.

To check on DDF’s health value, view the DSNV507I message that’s displayed as part of the
–DISPLAY THREAD(*) TYPE(SYSTEM) command and the DSNL094I message displayed as part of the output from the –DISPLAY DDF DETAIL command. A sample of the DSNL094I message is contained in the –DISPLAY output.

Additional References

The best resource for additional information about the subsystem parameters discussed here is the DB2 11 Installation and Migration Guide (GC19-4056). Of course, the DB2 11 for z/OS Information Center available on the Web contains the most current DB2 product details. There are also a couple of excellent Redbooks available to satisfy your distributed curiosity. Check out DB2 9 for z/OS: Distributed Functions (SG24-6952-01) and Jim Pickel’s DB2 9 for z/OS Data Sharing: Distributed Load Balancing and Fault Tolerant Configuration (REDP-4449). Although both Redbooks are at a lower DB2 release level, they’re still excellent DB2 for z/OS distributed processing resources.


3 Pages