PM82301: GET DOWN LEVEL PAGE FOR LOB OBJECTS AND CAUSE ABENDS LIKE DSNOGLOB 5008 ALSO CAUSED STORAGE OVERLAY13/02/08PTF PECHANGE

APAR status

• Closed as program error.

Error description

• users could get down level page for lob objects defined
  with GBPCACHE SYSTEM. It caused storage overlay. SMCOVERLAY
  DB2OVRLAY/K
  sequence of events.
  --
  1. member A updates a lob data page and writes it out to dasd.
  2. LOB becomes non-GBP-dependent.
  3. LOB becomes GBP-dependent again.
  4. Member A reformats(no-read GetPage) the page in it's local
  buffer pool and doesn't register the page to GBP
  5. Member A writes reformated page out to DASD.
  6. Meber B gets page from DASD, updates it and writes it to
  DASD.
  7. Member A tests the page in it's local buffer pool and thinks
  it's valid, so it go ahead reads the page from it's local buffer
  pool.
  --
  
  Since member A doesn't register the page at step 4, it doesn't
  receive cross invalidat at step 6. at step 7, it reads page from
  it's local buffer pool and skip updates made by member B at step
  Other possible symptoms:
  ABENDS0C4 0C4 00000010 RC10 PIC10
  DSNB5PCO M=DSNTFRCV LOC DSNVSRX DSNVSRRX OFFSET03BE
  where the thread is the 010.PCOPCO01 thread
  ABEND0C4 00000038 RC38 PIC38
  DSNTFRCV LOC=DSNIDM DSNB1REL OFFSET011C
  ABND 04E 00C90101 M=N C=101 RDS -SQL
  DSNTFRCV LOC=DSNIDM DSNOTCSO 5063 ERQUAL5063
  ABENDS0C6 ABEND0C6 0C6 00000006 RC06
  DSNB5PCO M=DSNTFRCV PSW=470C200189094203 A=00D7
  

Local fix

• ALTER lob objects from GBPCACHE SYSTEM to GBPCACHE CHANGE.
  

Problem summary

• ****************************************************************
  * USERS AFFECTED: DB2 data sharing users, with table spaces or *
  *                 indexes defined as GBPCACHE NONE, or LOB     *
  *                 spaces defined as GBPCACHE SYSTEM, and with  *
  *                 PM67544 (UK82633) and OA38419 (UA66420,      *
  *                 UA66421) applied, and with coupling          *
  *                 facilities at CFLEVEL 17 or higher.          *
  ****************************************************************
  * PROBLEM DESCRIPTION: Lost 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.                    *
  *                                                              *
  *                      If the object of the page regression    *
  *                      is a LOB space and the regression       *
  *                      results in a page type changing, a      *
  *                      massive storage overlay may occur.      *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  A timing window exists in which DB2 may fail to register a
  page for a GBP-dependent pageset, with the result that the
  member does not get cross-invalidated when another member
  updates the page, potentially resulting in broken data.
  
  The window only exits if the following conditions are met:
   - this member was the last to update the page before the
     object became non-GBP-dependent.
   - this same member was the first to update the page when
     the object became GBP-dependent again.
   - the page was still resident in the local buffer pool
     from the prior update.
   - the first update after becoming GBP-dependent again was
     to completely reformat the page.
   - the page gets written directly to DASD due to the page
     set being GBPCACHE NONE or GBPCACHE SYSTEM.
  
  If PM67544 (UK82633) is not installed, or if OA38419 (UA66420,
  UA66421) is not installed, or if the GBP is allocated in a CF
  with a CFLEVEL less than 17, then the page would have been
  implicitly cross-invalidated when the object went
  non-GBP-dependent, so no data integrity exposure would exist.
  

Problem conclusion

• DB2 has been fixed to ensure that a page being reformatted is
  registered to the CF, regardless of whether it was previously
  registered during a prior period of GBP-dependency.
  

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:

  UK92353

Modules/Macros

• DSNB1AGB DSNB1CMD DSNB1CNE DSNB1GC1 DSNB1GET
  DSNB1PMI DSNB5DEL DSNB5PCO
  

Fix information

• Fixed component name

  DB2 OS/390 & Z/

• Fixed component ID

  5740XYR00

Applicable component levels

• RA10 PSY

     UP