A fix is available
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.
[{"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