OA41994: VERY LARGE PARTIAL SVC DUMPS DUE TO MAXSPACE OR COMPLETE SVC DUMPS WITH SOME HIGH VIRTUAL COMMON STORAGE MISSING

Obtain the fix for this APAR.

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