IBM Support

OA44485: IEA412I SLIP TRAP ID=IBM, 1 SDUMPS NOT SCHEDULED. RETURN CODE=08, REASON CODE=02. DUMPSRV must be recycled.

A fix is available

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • Customer had an address space go through Memterm at the
    same time a dump was being taken of the address space.
    Messages are as follows:
    IEA794I SVC DUMP HAS CAPTURED: 170
            DUMPID=006 REQUESTED BY JOB (ITMTEMS )
            DUMP TITLE=ISSUER=IEFAB4ED,ERRCSECT=IEFAB4ER,
            COMPID=5752SC1B4,COMPON=DEVICE ALLOCATION-SUBCOMPONENT
            UNKNOWN
    IEF402I ITMTEMS  FAILED IN ADDRESS SPACE 02AE
            SYSTEM ABEND S40D - REASON CODE 10
    IEA611I PARTIAL DUMP ON test.system.D146.T020752.S00006
            DUMPID=006 REQUESTED BY JOB (ITMTEMS )
            FOR ASIDS(02AE,0016)
            INCIDENT TOKEN: SYSPLEX     01/26/2014 04:07:52
            SDRSN = 00000000 00200000 02000000 00000000
            SOME STORAGE COULD NOT BE DUMPED RC=4
            ERROR ID = SEQ01713 CPU00 ASID02AE TIME02.07.52.5
    From this point on - any DUMP command or SDUMP/SDUMPX macro will
    fail with RC=08 RSN=02 - System is unable to schedule a dump.
    SLIP traps will fail with IEA412I RETURN CODE=08 REASON CODE=02.
    
    DUMPSRV will remain serialized until a recycle of DUMPSRV is
    done with a CANCEL command.
     ANALYSIS:
        The partial dump shows that the dump included multiple asids
    
     in the RTCTASTB:
     SDAS  SDF4  SDF5
     02AE   F8    00
     0016   F8    00
     RTCTSDRM and RTCTSDTR are on for asid x'2AE' indicating that
     the DUMP task got posted and got control before the MEMTERM
     happened and IP VERBX IEAVTSFS shows that the dumping for
     local storage of asid x'2AE' never completed:
     Asid 02AE:
       Local storage start             01/26/2014 02:07:52.604029
       Local storage end               09/17/2042 21:53:47.370496
       Local storage capture time      19:45:54.766466
     A display of storage after the partial dump is complete
     shows the RTCTASTB incorrectly has the same two asids:
     SDAS  SDF4  SDF5
     02AE   D9    00
     0016   D9    02
     A display of CVTSDBF shows that dumpsrv is locked:  80BDA000
     There is a timing window such that:
       1.  IEAVTSDR is processing the memterm for asid x'2AE' and
           determines that the address space terminating is in the
           process of taking a dump so turns on RTCTSDDO for
           asid x'2AE' along with turning off RTCTSDAN and RTCTSDEN
       2.  At the same time, IEAVTSDT is finishing up the dump
           asid x'16' and checks to see if we are the last ASID in
           CHKLAST.  Since asid x'2AE' has RTCTSDDO on, RTCTSDLA
           is set to x'16' making it is the LASTASID.  IEAVTSCC
           issues IEA794I and tries to UNLOCK the dump in IEAVTSXS.
           Since RTCTCTSL has not been turned off - SXSUNLCK leaves
           the dump locked and returns to IEAVTSDT who completes.
       3.  IEAVTSDR finally gets to the point in ASID x'2AE' where
           it turns off RTCTCTSL and zeroes RTCTCTSA.   Since it is
           NOT the 'last asid', it does not attempt to unlock the
           dump.
     This window leaves the dump locked (i.e. CVTSDBF has the high
     order bit on) so any subsequent dump attempts will get 'system
     is unable to schedule a dump' .
     KNOWN IMPACT:
     Unable to obtain svc dumps.
     VERIFICATION STEPS:
     Verification Steps:
     1.  Find IEA412I SLIP TRAP ID=IBM, 1 SDUMPS NOT SCHEDULED.
         RETURN CODE=08, REASON CODE=02 in syslog or any evidence
         of a SDUMP/SDUMPX failing with RC=08 RSN=02
     2.  Look for last dump taken - should be indicated by
         IEA611I PARTIAL DUMP message.  The job/ASIDs involved
         in the dump will be indicated in the IEA611I message.
     3.  Look for IEF402I indicating that there was a failure
         in an address space.   If the asid number in the IEF402I
         matches the asid number in the IEA611I message then your
         problem is a match for this APAR.
     ADDITIONAL SYMPTOMS:
     iea402i
    

Local fix

  • RECOVERY ACTION:
     Cancelling DUMPSRV "CANCEL DUMPSRV" will cause dump processing
     to unlock and DUMPSRV will automatically restart allowing you
     to take dumps again.
    

Problem summary

  • ****************************************************************
    * USERS AFFECTED: All users of SVC dumps                       *
    ****************************************************************
    * PROBLEM DESCRIPTION: MSGIEA794I SVC DUMP CAPTURED received   *
    *                      in proximity to MSGIEF402I jobname      *
    *                      FAILED IN ADDRESS SPACE # SYSTEM ABEND  *
    *                      S40D - REASON CODE 10                   *
    *                      and no more dumps being taken           *
    *                                                              *
    ****************************************************************
    * RECOMMENDATION:                                              *
    ****************************************************************
    The problem can occur when an address space goes through
    Memterm at the same time that a dump was being taken of the
    address space. SDUMP processing can remain locked, preventing
    any further dumps from being taken.
    The originating condition may be indicated by the close
    proximity of MSGIEA045I AN SVC DUMP HAS STARTED and MSGIEA794I
    SVC DUMP HAS CAPTURED with the indication that a MEMTERM has
    occurred, like MSGIEF402I jobname FAILED IN ADDRESS SPACE ####
    SYSTEM ABEND S40D - REASON CODE 10
    

Problem conclusion

  • Correct SDUMP processing to remove, at earlier points in
    processing, the indication that IEAVTSDX will unlock, if its
    address space is being MEMTERMed.
    

Temporary fix

Comments

APAR Information

  • APAR number

    OA44485

  • Reported component name

    SDUMP/ABDUMP

  • Reported component ID

    5752SCDMP

  • Reported release

    790

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    YesSpecatt / CST / Xsystem

  • Submitted date

    2014-02-13

  • Closed date

    2014-07-23

  • Last modified date

    2014-09-08

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

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

    UA74278 UA74279 UA74280

Modules/Macros

  • IEAVTSDR
    

Fix information

  • Fixed component name

    SDUMP/ABDUMP

  • Fixed component ID

    5752SCDMP

Applicable component levels

  • R770 PSY UA74278

       UP14/08/06 P F408

  • R780 PSY UA74279

       UP14/08/06 P F408

  • R790 PSY UA74280

       UP14/08/06 P F408

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":"790","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":"790","Edition":"","Line of Business":{"code":"","label":""}}]

Document Information

Modified date:
08 September 2014