A fix is available
APAR status
Closed as program error.
Error description
Issuers of some privileged CP commands may hang in some situations. For example, a class B user can issue the SET MDCACHE command to change settings for another user. If the other user logs off during command processing, the command issuer can become hung.
Local fix
N/A
Problem summary
**************************************************************** * USERS AFFECTED: All users of z/VM * **************************************************************** * PROBLEM DESCRIPTION: * **************************************************************** * RECOMMENDATION: APPLY PTF * **************************************************************** The hang occurs when a CFM annex and logoff occur for the same VMDBK at the same time. The customer hit this problem with a vendor-added-code query command but the problem is in CP's HCPCFM code. It can occur if one of the following processes has a target userid that is logging off at the same time as the command or diagnose processing is in progress. ATTACH Crypto DETACH Crypto SET MDCACHE SET VMRELOCATE Diagnose x'290' The problem is that HCPCFM at label LOGOFF does not check the promote/annex CPE field (VMDPACPE) in the VMDBK before allowing the logoff to proceed. This can lead to a VMDBK being logged off while there is still outstanding CFM annex work pending. Promote to CFM does not have this problem because the VMDBK must be in i-stream before a promote CPEBK can be stored in VMDPACPE, so label LOGOFF in HCPCFM can never be reached under that circumstance.
Problem conclusion
The fix checks for VMDPACPE work at label LOGOFF in HCPCFM before allowing the logoff to continue. The following logic is inserted at label LOGOFF in HCPCFM. If this is the origin VMDBK then determine if there is a CFM annex in progress. If not (VMDPACPE = 0), put x'FFFFFFFF' into VMDPACPE so HCPCFMAN does not try to start a new annex. If VMDPACPE=x'FFFFFFFF' logoff has already started so just continue with the logoff. Otherwise an annex is in progress so go deal with it. at label CFMGTPAC. Also the register to hold the origin VMDBK address is moved from R4 to R15 because the branch to CFMGTPAC requires it in R15.
Temporary fix
********* * HIPER * ********* FOR RELEASE VM/ESA CP/ESA R640 : PREREQ: NONE CO-REQ: NONE IF-REQ: NONE FOR RELEASE VM/ESACP/ESAR710 : PREREQ: NONE CO-REQ: NONE IF-REQ: NONE
Comments
APAR Information
APAR number
VM66396
Reported component name
VM CP
Reported component ID
568411202
Reported release
710
Status
CLOSED PER
PE
NoPE
HIPER
YesHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2020-05-28
Closed date
2020-07-15
Last modified date
2021-06-29
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
UM35693 UM35694
Modules/Macros
HCPCFM
Fix information
Fixed component name
VM CP
Fixed component ID
568411202
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":"BU011","label":"Systems - zSystems software"},"Product":{"code":"SG27M"},"Platform":[{"code":"PF054","label":"z\/OS"}],"Version":"710","Line of Business":{"code":"LOB16","label":"Mainframe HW"}}]
Document Information
Modified date:
30 June 2021