PK50881: TASK STUCK IN CDB2RDYQ WAIT. CAN HAPPEN FOLLOWING ABEND OF DB2 AND CAN CAUSE CICS TO NOT BE ABLE TO RECONNECT TO DB2 .

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• Following an abend of DB2, the CICS/DB2 connection ( DB2CONN )
  remained stuck in DISCONNECTING status.  As a result, when
  DB2 was restarted, CICS could not reconnect to DB2.
    The reason CICS remains in DISCONNECTING status is because
  2 of the tasks that were trying to do DB2 SQL calls are stuck in
  a CDB2RDYQ wait, waiting for a Pool thread.
     This problem happens in the following circumstance:
  - A Transaction's DB2ENTRY specifies THREADWAIT(POOL) and
     tasks start using Pool threads.
  - There are enough tasks needing pool threads such that there
     are more tasks waiting on pool threads than there are
     pool threads.  For instance, here are DB2 Connection
     statisics showing this:
      Total number of Pool Thread Waits . . . . . :         12
  Pool Thread Limit . . . . . . . . . . . . . :         10
  Peak number of Pool Threads in use. . . . . :         10
  Peak number of Pool tasks . . . . . . . . . :          0
  Total number of Pool tasks. . . . . . . . . :          0
  Peak number of tasks on the Pool Readyq . . :         12
  --------------------------------------------------------
  The Peak number of tasks on the Pool Readyq is 2 more
  than the Pool Thread limit.
  .
  - The tasks that are using the pool threads don't terminate
     the DB2 thread in a normal manner.  In this example,
     it is because DB2 was abending that this happened.  When
     this happens, the tasks that were using the pool threads
     do not give their pool thread to one of the waiting tasks.
     Instead, one of the waiting tasks is posted and then
     gets an entry thread.  Eventually, there will be no more
     tasks using pool threads but there are still tasks waiting
     for a pool thread.
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All                                          *
  ****************************************************************
  * PROBLEM DESCRIPTION: Tasks which were in CDB2RDYQ wait when  *
  *                      DB2 abends, remain so after DB2 restart *
  *                      and can cause CICS to not be able to    *
  *                      reconnect to DB2.                       *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  Following an abend of DB2, some tasks which were in CDB2RDYQ
  wait for the pool at the time of the abend remain in the same
  state after DB2 restarts, and they prevent CICS from being able
  to reconnect to DB2.
  Keywords: OVERFLOW DFHAP0604 DFHDB2015 MSGDFHAP0604
            MSGDFHDB2015
  

Problem conclusion

• DFHD2EX1 has been amended such that a check is now made as to
  whether DB2 has shutdown at the point at which tasks which were
  in a CDB2RDYQ wait are re-started. If DB2 has shutdown, at this
  point, these tasks are now abended AEXY.
  

Temporary fix

• FIX AVAILABLE BY PTF ONLY
  

Comments

APAR Information

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

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

  PK56548 UK32769 UK32770

Modules/Macros

•    DESD2EX1 DFHD2EX1
  

Fix information

• Fixed component name

  CICSTS V3 Z/OS

• Fixed component ID

  5655M1500

Applicable component levels

• R400 PSY UK32769

     UP08/01/10 P F801

• R500 PSY UK32770

     UP08/01/10 P F801

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.