IBM Support

PM79520: MULTIPLE ABENDS INCLUDING 00C90101 / 00C90206 / 00C90207 SEEN IN DSNICUMW 5003 / DSNIDIFS 5007 / DSNIOW 5003

A fix is available


You can track all active APARs for this component.


APAR status

  • Closed as program error.

Error description

  • Multiple abends including:
    RC00C90101 seen at DSNICUMW ERQUAL5003
     RC00C90206 seen at DSNIIDIS ERQUAL5002 and DSNIDIFS ERQUAL5007
     RC00C90207 seen at DSNIOW   ERQUAL5003
    MSGDSNI014I DATA IN USE DURING ABEND message also displayed with
    the 00C90101 abend.
    with the 00C90206 and 00C90207 abends.
    Analysis of LOG data indicated Spacemap (SMAP) regression had

Local fix

  • REBUILD INDEX.  If that fails, then REORG TABLESPACE.

Problem summary

  • ****************************************************************
    * USERS AFFECTED: DB2 data sharing users.                      *
    * PROBLEM DESCRIPTION: Lost spacemap updates in data sharing.  *
    *                                                              *
    *                      Corrupted data can result in any of     *
    *                      the following symptoms:                 *
    *                       - Incorrect output, INCORROUT.         *
    *                       - ABEND04E RC00C90101, RC00C90102,     *
    *                         RC00C90105, or RC00C902xx in         *
    *                         various CSECTs.                      *
    *                       - Data/index inconsistencies reported  *
    *                         by the CHECK INDEX utility.          *
    *                       - Page regression reported by the      *
    *                         DSN1LOGP utility.                    *
    * RECOMMENDATION:                                              *
    If a spacemap page P-lock was once held in X mode and then later
    negotiated to S mode, it may persist past the physical closure
    of the pageset.  If this happens, and if the pageset is reopened
    and the page P-lock requested again, there is a timing window
    possible with the stealing of the old page buffer, which can
    leave DB2 thinking the P-lock is held when it has in fact been
    released.  This can result in the spacemap page being regressed
    and data being broken.

Problem conclusion

  • DB2 has been modified to ensure that S-mode page P-locks will
    always be released when the pageset is physically closed.
                   **  Important Note  **
    Data modifications (insertions, mass deletions) may have been
    lost, and if so, will not be recoverable by standard recovery
    procedures. The modifications will remain recorded on the DB2
    recovery log and can be recovered using tools such as the Log
    Analysis Tool. Rebuilding the index will make the Index
    consistent with the data but will not recover data that is
    missing nor attend to erroneously present data.  The same is
    true of reorganizing the object.  If in the interest of system
    availability indexes are rebuilt or the data is reorganized
    prior to determining if there is data loss, it is recommended
    that this action be followed with analysis and possible remedial
    action as outlined below.
    1. Run CHECK INDEX or CHECK DATA to help identify suspect tables
    and determine if any inconsistencies are detected by DB2.
    DSN1LOGP with the CHECK(DATA) option can also help identify
    suspect pagesets and data loss due to page regression.
    2. Use business application knowledge to aid in identification
    of suspect tables and any lost data.
    3. Use REBUILD INDEX to correct any immediate index-data
    mismatches, or use the REORG utility to correct other
    inconsistencies, unless reloading the table or recovering the
    table to a prior point in time.
    4. If inconsistencies are due to index errors and the data is
    determined to be correct then action is complete once the index
    is rebuilt.
    5. For cases where data loss is found, decide whether it is
    necessary to retrieve lost data updates. If it is not necessary,
    then action is complete once any inconsistencies are corrected.
    6. If it is necessary to retrieve lost data, then consider using
    a log analysis tool to regenerate DML for lost updates from the
    DB2 log. This requires that DB2 logs be preserved for this
    purpose. Alternatively restore data from other sources if

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:




Fix information

  • Fixed component name

    DB2 OS/390 & Z/

  • Fixed component ID


Applicable component levels

  • RA10 PSY UK91435

       UP13/02/21 P F302

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.

[{"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSEPEK","label":"Db2 for z\/OS"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"A1Z","Edition":"","Line of Business":{"code":"LOB10","label":"Data and AI"}},{"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SG19M","label":"APARs - z\/OS environment"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"A1Z","Edition":"","Line of Business":{"code":"","label":""}}]

Document Information

Modified date:
20 March 2013