PI81885: ABEND04E RC00C90101 DSNIBHRE ERQUAL5006

Obtain the fix for this APAR.

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 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

• RA10 PSY UI47908

     UP17/06/24 P F706 Ž

• RB10 PSY UI47909

     UP17/06/24 P F706 Ž

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.