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

A fix is available

Subscribe

You can track all active APARs for this component.

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 number

    OA39596

  • Reported component name

    SDUMP/ABDUMP

  • Reported component ID

    5752SCDMP

  • Reported release

    770

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    YesHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2012-05-15

  • Closed date

    2012-11-30

  • Last modified date

    2013-02-14

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



Rate this page:

(0 users)Average rating

Add comments

Document information


More support for:

z/OS family

Software version:

770

Operating system(s):

MVS, z/OS

Reference #:

OA39596

Modified date:

2013-02-14

Translate my page

Machine Translation

Content navigation