PM61082: DDF THREADS REMAIN ACTIVE EVEN THOUGH NO ACTIVE TRANSACTION(UOW)

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• DB2DDF DB2INACTIVE DB2XA defect pm61082 dpm61082
  DDF does not mark connections INACTIVE after DRDA ping and/or
  DRDA XA_RECOVER commands when there is no active
  UOW/transaction.
  
  Scenario:
  DDF, and thus perhaps the DB2 z/OS subsystem, does not shut
  down (QUIESCE) due to Java application threads/connections still
  in ACTIVE state. The JDBC driver sends a dummy EXCSAT DRDA(ping)
  command to DB2 z/OS without additional SQL. This causes the
  thread/connection to stay ACTIVE until a ROLLBACK or COMMIT is
  issued by the application.
  Java application using the JDBC driver issues isValid() call
  and the JDBC driver only flows EXCSAT DRDA command. This causes
  the thread/connection to remain ACTIVE.
  ***************************************************************
  Additional Symptoms and Keywords:
    DUMMY NULL EXCSAT PING
    XA_Recover XA Recover
    00D3003B RC00D3003B
    DSNTIPR DDF THREADS INACTIVE
    DSN6FAC CMTSTAT INACTIVE
    SQLCODE204 in application
    LOST SCHEMA SPECIAL REGISTER VALUE
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All Distributed Data Facility (DDF) users.   *
  *                 Specifically where DB2 is configured with    *
  *                 DDF THREADS=INACTIVE specified               *
  *                 (DSN6FAC CMTSTAT INACTIVE).                  *
  ****************************************************************
  * PROBLEM DESCRIPTION: Connection/DBAT remains active even     *
  *                      though it had only processed non SQL    *
  *                      related events, such as a DRDA Ping     *
  *                      and/or XA_Recover sequence.             *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  After servicing a DRDA Ping and/or XA_Recover sequence, the
  associated connection/DBAT remains active even though no actual
  SQL related transaction (Unit of Work, UOW) exists. This causes
  an unnecessary utilization of a DBAT that remains dedicated to
  the connection and therefore cannot be used (pooled) to service
  work on other connections.
  Potential symptoms may include:
  o Over utilization of DBATs, perhaps leading to an erroneous
    MAXDBAT limit reached condition.
  o Erroneous DSNL027I/DSNL028I message condition with a 00D3003B
    (Idle Thread Time-out exceeded) reason code.
  o A quiesce stop of DDF may not complete due to the erroneous
    presence of an active DBAT. A -STOP DDF MODE(FORCE) may be
    necessary in order for DDF to complete its stop processing.
  

Problem conclusion

• DB2 has been changed to recognize a DRDA Ping or XA_Recover
  sequence that is not part of a UOW and allow inactivation
  of the connection and pooling of the DBAT.
  

Temporary fix

Comments

• ž**** PE12/09/05 PTF IN ERROR. SEE APAR PM72269  FOR DESCRIPTION
  

APAR Information

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

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

  UK78127 UK78128

Modules/Macros

• DSNLQDIS DSNLTDSR DSNLTEXC
  

Fix information

• Fixed component name

  DB2 OS/390 & Z/

• Fixed component ID

  5740XYR00

Applicable component levels

• RA10 PSY UK78127

     UP12/05/05 P F205

• R910 PSY UK78128

     UP12/05/05 P F205

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.