A fix is available
APAR status
Closed as program error.
Error description
An abend occurred with the following title DSN ,ABND=04E-00C90101,U=SYSOPR ,M=N ,C=111.DMC -DSNIBHRE,M=DSNTFRCV,LOC=DSNIDM .DSNIBHRE:5006 . After this there were broken page messages for the page involved DSNI010I +DSN : BROKEN PAGE ACCESSED . Archive logs showed 3 records were not successfully deleted from a page and subsequent access to the page from the same UR to apply 3 inserts with same key weren't able to be applied as there was no room on the page. The page was inconsistent.
Local fix
Problem summary
**************************************************************** * USERS AFFECTED: DB2 for z/OS V10 and V11 users. * **************************************************************** * PROBLEM DESCRIPTION: Lost updates following multiple DB2 * * crashes. * * * * 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 table space or index is in read/write mode and DB2 crashes, and then gets updated again after restart, before DB2 has had a chance to convert it back to read-only, it needs to go through an abbreviated "pseudo-open" process even though it is already in read/write mode. This is due to the fact that there may or may not be an active SYSLGRNX entry. This pseudo-open will write an open log record and insert a SYSLGRNX row. There is a timing window where multiple agents may detect this situation and one may write an open log after an earlier one has already logged some updates. If DB2 crashes again, before the updated pages get written, the subsequent restart may fail to apply some log records, since it starts the log apply at the second open log. The missing log apply may leave the data inconsistent resulting in various "broken data" symptoms.
Problem conclusion
The pseudo-open logic has been modified, for the case of an update after a DB2 crash, to wait until after the conversion lock has been acquired to decide whether a new open log is necessary. This ensures that an open log will not be written after another agent has already started logging updates.
Temporary fix
********* * HIPER * *********
Comments
APAR Information
APAR number
PI81885
Reported component name
DB2 OS/390 & Z/
Reported component ID
5740XYR00
Reported release
B10
Status
CLOSED PER
PE
NoPE
HIPER
YesHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2017-05-19
Closed date
2017-06-09
Last modified date
2017-07-05
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
PI81886 UI47908 UI47909
Modules/Macros
DSNB1SWS
Fix information
Fixed component name
DB2 OS/390 & Z/
Fixed component ID
5740XYR00
Applicable component levels
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":"11.0","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":"11.0","Edition":"","Line of Business":{"code":"","label":""}}]
Document Information
Modified date:
05 July 2017