A fix is available
APAR status
Closed as program error.
Error description
An address space is going through EOM processing under the Master address space. A hang is detected by RTM while z/OS UNIX termination manager is attempting to cancel a waiting thread, resulting in aS30D abend. ANALYSIS: RTM under the Master address space invoked the z/OS UNIX resource recovery termination manager (BPXRRTRM) for EOM processing. BPXRRTRM next gave control to process termination (BPXPRTRM) using the syscall interface. The stack at time of abend shows the following call sequence: BPXJCPC->BPXPRTRM(UA99597)->BPXLKKW(UJ02237) z/OS UNIX Process termination found a waiting thread and attempted to cancel the kernel wait by invoking BPXLKKW(#cancel). The issue is that the wait was entered while running in the address space that is going through EOM processing. BPXLKKW checks the Kserascb field to determine under what address space the wait was issued. However, BPXPRTRM changes the Kserascb field to the currently running address space before invoking BPXLKKW thus causing BPXLKKW to incorrectly enter the wait. VERFICATION STEPS: 1) Abend30D under the Master Address space 2) wait was issued by BPXLKKW review the Linkage Stacks under the TCB that suffered the S30D abend and locate the linkage stack that issued the PC 030D R14=030D and the TARG = 00000000 0000030D The PSWE field should be an address within BPXLKKW 3) Verify that BPXLKKW was called by BPXPRTRM with parm #CANCEL.
Local fix
Problem summary
**************************************************************** * USERS AFFECTED: * * All users of z/OS UNIX System Services for HBB77B0 and * * HBB77C0 * **************************************************************** * PROBLEM DESCRIPTION: * * A process going through EOM and running in the master * * address space is hung, waiting for a POST. * * This results in ABEND30D - END OF MEMORY RESOURCE MANAGER * * HANG DETECTED. * **************************************************************** * RECOMMENDATION: * **************************************************************** During EOM for a process, USS resource recovery termination manager, BPXRRTRM gets control, running in the master address space. BPXPRTRM is called to cleanup Kernel resources. If there is an outstanding WAIT for a thread, BPXLKKW is called to cancel the WAIT. Before calling BPXLKKW, the KSERASCB field is changed from the ASCB for the processes in EOM to the master address space. When BPXLKKW CANCEL processing sees an outstanding WAIT, it checks the KSERASCB field and since it is the master address space (which is active), it continues waiting. Since any POST is directed to the process going though EOM and not the master ASID, the master ASID hangs and eventually receives an ABEND30D.
Problem conclusion
In BPXPRTRM, the ASID of the process going through EOM is saved in the KSER. When BPXLKKW is called to CANCEL the WAIT, it will see that the thread is in EOM, and the current active ASID (the Master ASID) is different than the original ASID. Since the original ASID is no longer active, the WAIT is cancelled.
Temporary fix
Comments
APAR Information
APAR number
OA60230
Reported component name
OPENMVS SYS SRV
Reported component ID
5695SCPX1
Reported release
7B0
Status
CLOSED PER
PE
NoPE
HIPER
YesHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2020-09-29
Closed date
2020-12-30
Last modified date
2021-04-09
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
UJ04698 UJ04699
Modules/Macros
BPXPRTRM BPXLKKW
Fix information
Fixed component name
OPENMVS SYS SRV
Fixed component ID
5695SCPX1
Applicable component levels
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"},"Platform":[{"code":"PF054","label":"z\/OS"}],"Version":"7B0"}]
Document Information
Modified date:
10 April 2021