PM66235: ABEND04E RC00E2000C FROM DSNSVSVB WHEN IFCID400 IS ACTIVE

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• ABEND04E R00E2000C from DSNSVSVB when turning on the IFCID400
  and running release deallocate packages.
  ACOMDSC2GP or STMT CACHE BLOCKS 2G is filled with SHTE and
  STMT text.
  .
  DB2STGLK/K
  

Local fix

• Turn off IFCID400
  

Problem summary

• ****************************************************************
  * USERS AFFECTED: All DB2 10 for z/OS users of DB2 packages    *
  *                 containing static SQL and COMMIT / ROLLBACK, *
  *                 bound RELEASE(DEALLOCATE) and run with       *
  *                 either DB2 trace IFCID 400 or trace monitor  *
  *                 class 29 active                              *
  ****************************************************************
  * PROBLEM DESCRIPTION: DB2 storage shortage in ACOMDSC2GP /    *
  *                      STMT CACHE BLOCKS 2G pool where the     *
  *                      pool contains an excessive number of    *
  *                      blocks with eye catcher 'SHTE',         *
  *                      resulting in DB2 out-of-storage         *
  *                         ABEND04E RC00E2000C                  *
  *                              at DSNGEPLC . DSNSVSVB +0AC2    *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  In DB2 10 when either DB2 trace IFCID400 or trace monitor
  class 29 is active, DB2 collects statement level statistics
  for each static SQL executed in a DB2 package. These statement
  level statistics are stored in DB2 internal block SHTE in
  the DB2 STMT CACHE BLOCKS 2G pool during the SQL stmt
  execution (note that when IFCID400 is active, both static and
  cached dynamic SQL share usage of this pool). This pool is
  shared across DB2 threads. There is one SHTE block per static
  SQL statement, and the different running copies of that static
  SQL statement used by different DB2 threads share that
  single SHTE block. The lifetime of this SHTE block used for
  static SQL statement level statistics is directly tied to
  the lifetime of both the running copies of the static SQL
  statement and the master copy of its DB2 package in the
  EDM POOL. When all of the running copies of the static SQL
  statement are freed and the master copy of the DB2 package
  in the EDM POOL is also LRU'd out when more EDM POOL space
  is needed for other packages, the internal SHTE block for
  the static SQL statement is also freed. If there is at least
  one copy of the static SQL statement still active for
  a DB2 package, the SHTE block for that static SQL statement
  is not freed.
                                                             .
  In the reported DB2 storage shortage case, a significant
  number of static SQL executions were from DB2 packages
  bound RELEASE(DEALLOCATE) and run while trace IFCID400
  was active. A DB2 thread's copy of a package bound
  as RELEASE(DEALLOCATE) and its static SQL statements will
  remain allocated until that DB2 thread is terminated.
  This means that the internal SHTE block will also remain
  allocated until all of the associated running copies of
  the RELEASE(DEALLOCATE) packages are freed at DB2 thread
  termination and the packages' master copies are LRU'd out
  of the EDM POOL.
  However, in this case, even though the DB2 threads were
  terminated, and the packages bound REL(DEALLOCATE) and their
  copies of the static SQL statements were freed, the internal
  SHTE blocks for these static SQL statements were not freed.
                                                             .
  DB2 Development determined that when the application program
  was bound REL(DEALLOCATE) and issued multiple COMMITs/
  ROLLBACKs (or single COMMIT/ROLLBACK followed by a DB2 implicit
  ending COMMIT), at DB2 thread termination/deallocation DB2 did
  not consider the static SQL that were run and COMMITed in the
  previous units-of-work (UOW). So at deallocation time DB2 did
  not 'de-register' the static SQL statement's usage of the
  internal SHTE block used for that statement.  Therefore, many
  SHTE blocks accumulated in the DB2 STMT CACHE BLOCKS 2G pool
  as if they were still in use by active static SQL statements,
  resulting in the DB2 storage shortage and the reported DB2
  abend.
  

Problem conclusion

• SOLUTION:
  DB2 thread termination/deallocation code has been changed to
  consider static SQL that were run and COMMITed in any previous
  UOW when either DB2 trace IFCID400 or trace monitor class 29
  was active, and to 'de-register' those static SQL statements'
  usage of the internal SHTE block for statement level statistics.
  
  
  RELATED KEYWORDS: 04E AB04E IFCID400 0400 OFFSET0AC2
                    SQLSTORAGE GROWTH LEAK DB2STGLK/K
  

Temporary fix

Comments

APAR Information

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

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

  UK81878

Modules/Macros

• DSNXEUFP
  

Fix information

• Fixed component name

  DB2 OS/390 & Z/

• Fixed component ID

  5740XYR00

Applicable component levels

• RA10 PSY UK81878

     UP12/10/03 P F210

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.