VM66396: USER HANGS AFTER ISSUING PRIVILEGED CP COMMAND

Obtain the fix for this APAR.

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

• R640 PSY UM35693

     UP20/12/16 P 2001 ¢

• R710 PSY UM35694

     UP21/06/29 P 2101 ¢

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.