A fix is available
APAR status
Closed as program error.
Error description
A problem exists where when dumping multiple address spaces and at least one of them has an interest in a high virtual shared memory object, the table used to track which high virtual common storage ranges to be included in the dump gets updated while it is actively being referenced to dump the HV common storage. Depending on how the table has changed, this can lead to dumping large ranges of unobtained high virtual common storage resulting in partial dumps due to MAXSPACE or missing ranges of high virtual common storage even though the dump is complete. Additionally this problem has been seen to result in many ABENDDC2 errors due to SDUMP passing to RSM HVShared storage ranges from an address space that has no interest in that range. Verification steps: For large dumps that are unexpectedly partial due to MAXSPACE: ---------------------------------------------------------------- 1) Dump is partial due to MAXSPACE as indicated by MSGIEA043I: IEA043I SVC DUMP REACHED MAXSPACE LIMIT - MAXSPACE=x MEG OR as indicated by IEA611I or IEA911E PARTIAL DUMP message with accompanying text: MAXSPACE LIMIT REACHED WHILE CAPTURING DUMP and partial dump reason code with bit 15 in the 3rd word on 2) When viewing the dump under option 4 (Inventory) and specifying the LZ (LISTZONE) option, the output shows ASID1 owning gigabytes of storage. To locate this, do: FIND DESCRIBE two times. This will get you to the end of the section describing data dumped for ASID1. The line includes a total, and if you have a MAXSPACE of several Gig, then this total will also be several Gig: X'y_yyyyy000' bytes described in ASID(X'0001') 3) Gather all of the obtained high virtual common storage ranges from an IP RSMDATA HVCOMMON report. 4) Review the IP RSMDATA HVSHRDATA report to see if any of the address spaces that were dumped have an interest in a high virtual shared memory object. 5) If there are large ranges from step 2 above that are not covered by the ranges found in step 3 and at least one of the address spaces included in the dump have an interest in a high virtual shared memory object, this is most likely your APAR. For complete dumps that are missing ranges of HV common storage: ---------------------------------------------------------------- 1) The dump will be complete according to message IEA611I or IEA911E. 2) When viewing the dump, expected ranges of high virtual common storage will be missing (storage not available). 3) Review the IP RSMDATA HVSHRDATA report to see if any of the address spaces that were dumped have an interest in a high virtual shared memory object. 4) If at least one of the address spaces included in the dump have an interest in a high virtual shared memory object and high virtual common storage is missing from a complete dump, this may be your APAR. Additional keywords: HVCOMMON HVSHARED msgIEA611I msgIEA911E
Local fix
If this problem is suspected, limit dumps to 1 address space at a time.
Problem summary
**************************************************************** * USERS AFFECTED: All users of SVC dumps * **************************************************************** * PROBLEM DESCRIPTION: Extra, or missing HV Common storage in * * SVC Dumps * **************************************************************** * RECOMMENDATION: * **************************************************************** The problem can occur in certain situations when dumping applications whose address spaces are using high virtual shared storage. While dumping high virtual Common storage, SVC dump processing could capture more, or less, data than what was requested. For 790 only, certain JES2 dumps were partial due to dataspace access issues (ABEND0C4 IEAVTSDO)
Problem conclusion
IEAVTSDO processing was changed to prevent incorrect processingof HVCommon storage ranges, in the shared range table. For 790 only, additional changes were made to correctly capture data for JES2 dumps.
Temporary fix
********* * HIPER * *********
Comments
APAR Information
APAR number
OA41994
Reported component name
SDUMP/ABDUMP
Reported component ID
5752SCDMP
Reported release
780
Status
CLOSED PER
PE
NoPE
HIPER
YesHIPER
Special Attention
NoSpecatt
Submitted date
2013-04-15
Closed date
2013-05-30
Last modified date
2013-11-01
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
UA69324 UA69325 UA69326 UA69327
Modules/Macros
IEAVTSDO IEAVTSDV
Fix information
Fixed component name
SDUMP/ABDUMP
Fixed component ID
5752SCDMP
Applicable component levels
R770 PSY UA69324
UP13/06/12 P F306
R78H PSY UA69327
UP13/06/12 P F306
R780 PSY UA69325
UP13/06/12 P F306
R790 PSY UA69326
UP13/06/12 P F306
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":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SG19M","label":"APARs - z\/OS environment"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"780","Edition":"","Line of Business":{"code":"","label":""}},{"Business Unit":{"code":null,"label":null},"Product":{"code":"SG19O","label":"APARs - MVS environment"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"780","Edition":"","Line of Business":{"code":"","label":""}}]
Document Information
Modified date:
01 November 2013