PM60349: DSNSRSUP RECOVERY MAY CAUSE SEGMENTS TO BE MOVED TO PHBRSHB. MAY AFFECT ECSA OR DB2 ASID 31BIT PRIVATE STORAGE.

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• DSNSRSUP recovery for 31bit variable pools may cause all
  segments to be marked as bad and placed on the phbrshb chain if
  recovery is entered and the pool is analyzed.  This is
  transparent on thread pools since they would be reset or
  deallocated somewhat frequently but for system pools, can result
  in loss of ECSA or private storage if pools are hit often.
  

Local fix

• N/A
  

Problem summary

• ****************************************************************
  * USERS AFFECTED: All DB2 V10 users.                           *
  ****************************************************************
  * PROBLEM DESCRIPTION: ECSA or private 31bit storage may be    *
  *                      lost to the system for the duration of  *
  *                      this DB2 instance if the abend occurs   *
  *                      while within DB2 storage mananger code. *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  When threads abend while in DB2 storage manager 31bit variable
  storage code holding any of the latches used to serialize
  storage management, the recovery module dsnsrsup would receive
  control.  As part of the recovery process, it attempts to
  validate that the storage pool still has integrity by analyzing
  the segments. The code to do this segment verification, failed
  to count the bytes attributed to being quad word bounded so the
  length of the segment didn't match the byte count.  When this
  occurs, those segments are placed on the phbrshb damaged segment
  chain so that no new storage is allocated from them. They are
  not freed, since portions of the storage may still be in use.
  The available ECSA or DB2 address space private 31bit storage
  may be reduced for the duration of this DB2 instance if the
  abends occur while the abending thread is within DB2 storage
  manager code, and the abending thread is accessing one of the
  system pools. Only a recycle of DB2 will recover the affected
  storage in that case.
  RC00E20003,RC00E2000B,RC00E2000C,RC00E2000D,RC00E20011
  RC00E20013,RC00E2001F,RC00E20021,RC00E20022,RC00E20025
  RC00E20001,RC00E50013
  L2 Diagnosis:
  If this apar is the cause of the shortage, a phb with the
  affected storage type will be found having a very large chain
  of shbs, starting with phbrshb. Logrec entries for the affected
  phb should also exist, showing SMC recovery was entered.
  

Problem conclusion

• The recovery code has been changed to properly calculate the
  number of bytes in each segment while making the validation
  check.
  

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:

  UK78277

Modules/Macros

• DSNSRSUP DSNSVBK
  

Fix information

• Fixed component name

  DB2 OS/390 & Z/

• Fixed component ID

  5740XYR00

Applicable component levels

• RA10 PSY UK78277

     UP12/05/16 P F205

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.