IBM Support

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

A fix is available

Subscribe

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.
    
    MSGDSNI013I POTENTIALLY INCONSISTENT DATA message also displayed
    with the 00C90206 and 00C90207 abends.
    
    Analysis of LOG data indicated Spacemap (SMAP) regression had
    occurred.
    

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
    possible.
    ================================================================
    

Temporary fix

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

Comments

APAR Information

  • APAR number

    PM79520

  • Reported component name

    DB2 OS/390 & Z/

  • Reported component ID

    5740XYR00

  • Reported release

    A1Z

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    YesHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2012-12-19

  • Closed date

    2013-02-05

  • Last modified date

    2013-03-20

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

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

    UK91435

Modules/Macros

  •    DSNB1CBP DSNB1CFC DSNB1GWB DSNB1REL DSNB1RRR
    DSNB1RWI DSNB5COM DSNB5SCM
    

Fix information

  • Fixed component name

    DB2 OS/390 & Z/

  • Fixed component ID

    5740XYR00

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.



Document information

More support for: DB2 for z/OS

Software version: A1Z

Reference #: PM79520

Modified date: 20 March 2013


Translate this page: