PK69339: AUTOMATIC KEEPDYNAMIC DISTRIBUTED THREAD REFRESH

A fix is available

 

APAR status

  • Closed as new function.

Error description

  • DB2DDF DDFL09 DB2INACTIVE feature pk69339 fpk69339
    Automatic refresh of distributed thread (DBAT) which uses
    packages bound with keepdynamic(yes)
    *******************************************************
    Additional symptoms and keywords:
    DBAT KEEPDYNAMIC REFRESH
    Short on Storage SOS
    KeepDynamic Keep Dynamic

Local fix

Problem summary

  • ****************************************************************
    * USERS AFFECTED: All Distributed Data Facility (DDF) users. *
    * Specifically where DB2 is being accessed *
    * by distributed applications using the IBM *
    * Data Server Driver or Client product family *
    * and the packages utilized by the application *
    * were bound with KEEPDYNAMIC(YES). *
    ****************************************************************
    * PROBLEM DESCRIPTION: Task abends occur due to storage *
    * getmain calls failing which were *
    * caused by the fragmentation of the *
    * virtual storage within the *
    * ssidDBM1 address space. *
    ****************************************************************
    * RECOMMENDATION: *
    ****************************************************************
    When distributed client applications utilize packages
    that have been bound with KEEPDYNAMIC(YES), the distributed
    threads (DBATs) remain active with the connection. The reason
    for the thread remaining active is a local prepared statement
    cache is created for the application session so that the
    application only needs to execute a statement once it has been
    prepared, regardless of whether or not a commit has been
    performed. Without KEEPDYNAMIC(YES) on the packages, the
    application would have to always reprepare a statement prior
    to executing the statement if a commit had been performed
    since the last time the statement was prepared. The thread
    can then potentially remain active with the connection for
    an extended period of time. As the thread accumulates new
    prepared statements over time, the thread's storage footprint
    in the ssidDBM1 address space will grow. Also, over time, as
    the storage is acquired and possibly released by the thread
    due to different application statements being processed, the
    virtual storage within the ssidDBM1 address space could be
    fragmented in such a way that requests for storage within
    the address space for this and other threads will fail.
    These storage failures will result in task abends and
    application outages.

Problem conclusion

Temporary fix

Comments

  • DDF has been changed to support a concept called KeepDynamic
    DBAT refresh. This support requires that the DDF THREADS
    (DSN6FAC CMTSTAT) subsystem parameter be set to INACTIVE.
    Also, this support can only be activated for a DBAT which is
    serving a connection from an application using the IBM Data
    Server Driver or Client for JAVA. The driver/client must
    connect directly to DB2 9 for z/OS and the driver/client must
    have support for Sysplex Workload Balancing and/or Seamless
    Failover. The DataSource used by the application must have
    the "enableSysplexWLB" property set to true or the
    "enableSeamlessFailover" set to true. Since the application
    is utilizing KeepDynamic capabilities, the DataSource must
    also have the required KeepDynamic properties set.
    When DDF receives a connection request from such an appli-
    cation session, DDF will now be able to terminate the
    the DBAT/connection after it has been used for over one hour
    or it has remained idle for over 20 minutes. This connection
    outage will then cause the client/driver to redrive a new
    connection against the same server or a possibly different
    member of the serving data sharing group.
    The application should be able proceed as if nothing happened
    to its connection. By terminating the DBAT/connection, DDF
    will have temporarily alleviated the virtual storage demand
    within the ssidDBM1 address space, allowing the DB2 subsystem
    to continue operations unabated.
    ž**** PE09/12/01 FIX IN ERROR. SEE APAR PM02383 FOR DESCRIPTION

APAR Information

  • APAR number

    PK69339

  • Reported component name

    DB2 OS/390 & Z/

  • Reported component ID

    5740XYR00

  • Reported release

    910

  • Status

    CLOSED UR1

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    YesSpecatt / New Function

  • Submitted date

    2008-07-21

  • Closed date

    2009-09-28

  • Last modified date

    2010-01-04

  • APAR is sysrouted FROM one or more of the following:

  • APAR is sysrouted TO one or more of the following:

    UK50565

Modules/Macros
DSNDDPSB DSNLAGNX DSNLBABR DSNLEDDA DSNLQACT DSNLQCTL
DSNLQDIS DSNLTEXC        

Fix information

  • Fixed component name

    DB2 OS/390 & Z/

  • Fixed component ID

    5740XYR00

Applicable component levels

  • R910 PSY UK50565

       UP09/10/13 P F910

Fix is available

  • Select the PTF appropriate for your component level. You will be required to sign in. Distribution on physical media is not available in all countries.

Rate this page:

(0 users)Average rating

Document information


More support for:

DB2 for z/OS

Software version:

910

Reference #:

PK69339

Modified date:

2010-01-04

Translate my page

Machine Translation

Content navigation