OA39596: MANY ABENDDC2 RSN5F004022 OR RSN5F001A20 ENTRIES RECORDED TO LOGREC DURING DUMP CAPTURE

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• When capturing a dump of address spaces that have shared
  memory objects, many ABENDDC2s with rsn5F004022 or rsn5F001A20
  may be taken.  The ABENDs are taken when these address spaces
  are dumped along with other address spaces that either are not
  sharing the memory objects (rsn5F004022) or do not have any
  above the bar storage allocated (rsn5F001A20).  The number of
  ABENDs (none to many) can vary depending on timing and how much
  of the storage in the shared memory object resides on auxiliary
  storage.  This may lead to elongated dump capture time if many
  of these ABENDs are taken.  Logrec records will show the
  ABENDDC2s being taken by SDUMP CSECT IEAVTSDO.
  
    In all cases, the partial dump reason code will indicate an
  error occurred in SDUMP but the dump captured will contain the
  expected storage:
  
  SDRSN = 00000000 80000000 00000000 00000000
  ERROR OCCURRED IN SDUMP
  
  Updated 11/16/12: Additionally note that it is now strongly
  indicated that the serialization problem behind this APAR is
  also responsible for symptoms of very large SVC dumps that
  are partial due to MAXSPACE, in spite of a very generous
  MAXSPACE value.  These dumps show many, many pages in the
  range of HVSHARE storage dumped for ASID1.  These pages all
  contain zeros because they are actually unreferenced (and so
  were dumped in error).  While there are many users of HVSHARE
  storage, this problem has been seen primarily with DB2 and
  WEBSphere SVC dumps.  This problem is typically seen
  intermittently.  Customers experiencing impact from these
  very large "runaway dumps" should place their MAXSPACE at
  a conservative value that is compatible with their
  auxiliary and real storage configurations.
  
  
  Verification steps for symptoms of initially described problem:
  1) Logrec during the time of the dump will show many ABENDDC2s
     with rsn5F004022 or rsn5F001A20 taken in IEAVTSDO.
  2) The partial dump reason will indicate an error occurred in
     SDUMP.
  3) In the dump, an IP RSMDATA HVSHRDATA will show the high
     virtual shared memory objects allocated.  An IP CBF RTCT will
     show the address spaces included in the dump.  Some of the
     address spaces will share some of the memory objects while
     others will not have access to them.  The logrec entries
     should be for one of the included address spaces that does
     not have access to the shared memory objects.
  
  Verification Steps for additionally described problem (11/16)
  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 Gigs 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')
                                                        ..
  Additional keywords:
  IEA611I msgIEA611I IARV64 GETSHARED SHAREMEMOBJ sDC2 s0DC2
  5F004022 5F001A20 0040 001A SDRSDFRR IEAVTSRR
  

Local fix

•   To prevent the ABENDs, limit the dump to only include address
  spaces that are sharing memory objects if it is known/possible.
  

Problem summary

• ****************************************************************
  * USERS AFFECTED: All users of SVC dumps                       *
  ****************************************************************
  * PROBLEM DESCRIPTION: Long SVC dump times due to ABENDDC2     *
  *                      with RSN5F004022 or RSN5F001A20         *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  The problem occurs for SVC dumps (SDUMPs) requesting high
  virtual shared private storage, when multiple address spaces
  (a/s) are specified. It is possible that an a/s that has no
  access to that shared area, still attempts to reference it.
  This can result in multiple forms of ABENDDC2s. Since SDUMP
  processing handles the ABENDs as expected ones, the
  installation only sees the issue as SDUMPs taking a long time
  to complete. LOGREC entries may also be generated.
  

Problem conclusion

• SDUMP high virtual shared storage processing was corrected to
  prevent address spaces, with no access to shared virtual, from
  attempting to access it.
  

Temporary fix

• *********
  * HIPER *
  *********
  

Comments

• ž**** PE13/01/29 PTF IN ERROR. SEE APAR OA41315  FOR DESCRIPTION
  

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

  UA67367 UA67368 OA41315

Modules/Macros

•    IEAVTSDL IEAVTSDO IEAVTVSM
  

Fix information

• Fixed component name

  SDUMP/ABDUMP

• Fixed component ID

  5752SCDMP

Applicable component levels

• R770 PSY UA67367

     UP12/12/12 P F212

• R780 PSY UA67368

     UP12/12/12 P F212

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.