VM66066: HYPERPAV ALIAS SERIALIZATION IMPROVEMENTS

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• HyperPAV Alias serialization will be improved.
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All z/VM users of system attached HyperPAV   *
  *                 Alias devices.                               *
  ****************************************************************
  * PROBLEM DESCRIPTION:                                         *
  ****************************************************************
  * RECOMMENDATION: APPLY PTF                                    *
  ****************************************************************
  There are three problems addressed by this APAR:
  -
  1- ABENDPAJ003 occurs using HyperPAV Alias devices for paging.
  Currently there is nothing preventing a system attached hyperPAV
  Alias from being detached from the system while it is actively
  executing paging I/O on behalf of a HyperPAV base.  The I/O will
  still execute but subsequent processing for system HyperPAV
  Alias processing is incomplete because the alias is no longer
  attached to the system.
  -
  2- The CUIBK counter, CUIPGAL, indicating the amount of system
  attached HyperPAV Aliases currently in use by paging I/O is
  higher than the CUIBK counter, CUISYSAL, that indicates the
  total amount of system attached HyperPAV Aliases in the system.
  -
  3- ABENDIQM002 occurs when an I/O is started on a HyperPAV
  Alias device that is already active.
  After a HyperPAV Alias device is done executing I/O on behalf
  of a HyperPAV Base device and the HyperPAV Alias free queue
  is empty, HCPIQMDQ calls HCPHPVFB to find a HyperPAV Base with
  queued I/O that this alias can be used for.  During this
  process the HyperPAV Alias's RDEV lock is released and
  reobtained.  If a base is found with I/O to transfer to the
  alias device the RDEV lock for the alias is reobtained and some
  sanity checks are made (still a HyperPAV alias, still system
  attached and not associated with a HyperPAV Base device)
  and if all pass, then control is passed back to HCPIQMDQ and
  the I/O is started on the HyperPAV Alias device.  In this case,
  the Alias had an MIH IORBK (IRA = HCPIOSIG) on RDEVAIOR and
  a subsequent SSCH was issued for the HyperPAV Base I/O that
  was transferred to it causing an ABENDIQM002.
  

Problem conclusion

• Here are the three solutions associated with this APAR:
  -
  1- HCPHPVAA was modified to add one to RDEVLCNT in any HyperPAV
  alias where the field is zero after being copied from the
  assoicated HyperPAV base device.  This will prevent a detach
  from system while the alias is executing paging I/O on behalf
  of a base device and allow subsequent processing to execute
  appropriately.  Also, HCPPAVSW was updated to call HCPPAJRP for
  HyperPAV Paging I/O to allow an I/O that failed on a HyperPAV
  Alias device to be retried on the associated HyperPAV Base
  device correctly.
  -
  2- Serialization was tightened up in two different entry points
  in HCPHPV to resolve this problem.  First in HCPHPVAA (assign
  alias from the free pool), the RDEVLOCK is now obtained before
  examining an alias RDEV on the queue with some validity checks.
  This way if the device is a candidate, it is already locked down
  and status can't change.  In the past, validity checks were done
  without the lock and when the alias was deemed valid, THEN the
  RDEVLOCK would be obtained (allowing for some other process
  (like DETACH) to change the status of the alias).  Second,
  in HCPHPVRF (remove an alias from the free queue) there was a
  violation of the locking heirarchy.  The alias RDEV lock was
  already held when the HPPLOCK is being acquired.  This was
  changed to release the RDEV lock, acquire the HPPLOCK, and
  reacquire the alias RDEV lock so that locking heirarchy
  is followed to avoid deadlock.
  -
  3- HCPHPVFB was modified to check RDEVAIOR after the RDEV lock
  is reobtained for the HyperPAV Alias.  If RDEVAIOR is non-zero,
  then HCPHPVFB will exit with the HyperPAV Alias not doing any
  I/O for a HyperPAV Base.  This will prevent the ABENDIQM002.
  

Temporary fix

• *********
  * HIPER *
  *********
  FOR RELEASE VM/ESA CP/ESA R640 :
  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:

  UM35218

Modules/Macros

• HCPHPV   HCPPAV
  

Fix information

• Fixed component name

  VM CP

• Fixed component ID

  568411202

Applicable component levels

• R640 PSY UM35218

     UP17/09/13 P 1702 ¢

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.