IBM Support

PM46390: 04E-00C90102 WITH DSNIBHRE:0C01 AND 04E-00C90101 WITH DSNIBHRE:5005

A fix is available


You can track all active APARs for this component.

APAR status

  • Closed as program error.

Error description

  • The issue is limited to Group Restart and only if GRECP gets
    turned on during Group Restart, meaning group bufferpool went

Local fix

  • start only one member, let it finish through at least the end of
    Forward Log Recovery phase, and then start other members.

Problem summary

  • ****************************************************************
    * USERS AFFECTED: All DB2 for z/OS users of Group Restart      *
    *                 when the SCA structure is rebuilt (Group     *
    *                 Restart when only the Lock structure is      *
    *                 rebuilt is not affected by this APAR)        *
    *                      ABEND04E RC00C90101 DSNIBHRE ERQUAL5005 *
    *                      or similar abends may occur during      *
    *                      Group Restart with SCA rebuild due to   *
    *                      loss of the GRECP exception state on a  *
    *                      subset of data sharing members (the     *
    *                      abends occur on members that lost       *
    *                      GRECP)                                  *
    *                                                              *
    *                      If an affected object is an index,      *
    *                      abends would likely be in DSNKUNR2.     *
    * RECOMMENDATION:                                              *
    The aforementioned abends occurred during Group Restart with
    SCA rebuild, at some point after an object entered the GRECP
    state (MSGDSNB323I). The abends are due to the object's page
    containing unexpected information (e.g. bad page number field
    on the page). The reason for the page looking incorrect is that
    the GRECP state was lost in DBET for the abending member, which
    means that the page was no longer protected from being accessed.
    Investigation shows that the GRECP state was lost in DBET
    during early Forward Log Recovery phase of restart when the data
    sharing member mistakenly erased its GRECP information after
    copying down Group DBET content from the newly-built SCA.
    Specifically, while the member did keep GRECP information in its
    piece-level internal structure, it mistakenly erased it in its
    base-level internal DBET structure. Unfortunately, it is this
    base-level internal DBET structure that Buffer Manager and other
    callers use to check for GRECP existence when querying DBET.
    The object experiencing a loss of GRECP can be a table space or
    an index.

Problem conclusion

  • Code has been corrected to ensure that the Forward Log Recovery
    code in DBET does not lose GRECP information.

Temporary fix

  • *********
    * HIPER *


APAR Information

  • APAR number


  • Reported component name

    DB2 OS/390 & Z/

  • Reported component ID


  • Reported release


  • Status


  • PE




  • Special Attention


  • Submitted date


  • Closed date


  • Last modified date


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

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

    UK73590 UK73591 UK73592



Fix information

  • Fixed component name

    DB2 OS/390 & Z/

  • Fixed component ID


Applicable component levels

  • RA10 PSY UK73590

       UP11/11/22 P F111

  • R810 PSY UK73591

       UP11/11/22 P F111

  • R910 PSY UK73592

       UP11/11/22 P F111

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.

Document information

More support for: DB2 for z/OS

Software version: 810

Reference #: PM46390

Modified date: 02 December 2011

Translate this page: