A fix is available
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