A fix is available
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 number
PM60349
Reported component name
DB2 OS/390 & Z/
Reported component ID
5740XYR00
Reported release
A10
Status
CLOSED PER
PE
NoPE
HIPER
YesHIPER
Special Attention
NoSpecatt
Submitted date
2012-03-14
Closed date
2012-04-30
Last modified date
2012-06-03
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.
[{"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":"10.1","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":"10.1","Edition":"","Line of Business":{"code":"","label":""}}]
Document Information
Modified date:
03 June 2012