VM65367: HYPERSWAP MSS PROBLEMS

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• Multiple problems found in the hyperswap/MSS arena.
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All zVM users of Hyperswap and non-zero      *
  *                 subchannel sets.                             *
  ****************************************************************
  * PROBLEM DESCRIPTION:                                         *
  ****************************************************************
  * RECOMMENDATION: APPLY PTF                                    *
  ****************************************************************
  This APAR addresses four separate problems:
  -----
  PROBLEM 1: ABENDSIT002 on HYPERSWAP with TRSOURCED HPVALIASes
  -
  Environment: z/VM 6.3,GDPS 3.10 and SA MP 3.2.2.4.
  PPRC secondary devices are in non-zero subchannel set.
  HyperPAV alias devices are in subchannel set 0 for both source
  and target systems.
  -
  During unplanned and planned HYPERSWAPs an ABENDSIT002 occurs
  when the HyperPAV Alias devices, associated with the HyperPAV
  base devices being swapped, are being TRSOURCED traced.
  In the HyperPAV aliases RDEVs after the swap, RDEVTRC points
  to an old TRCBK for which the storage is already released
  causing the ABENDSIT002.
  -----
  PROBLEM 2: HyperPAV Aliases not being used after Hyperswap
  -
  Environment: z/VM 6.3,GDPS 3.10 and SA MP 3.2.2.4.
  PPRC secondary devices are in non-zero subchannel set.
  HyperPAV alias devices are in subchannel set 0 for both source
  and target systems.
  -
  Running with a high Linux I/0 load (each linux guest has an
  MDISK on the same real device), CP selected HyperPAV alias
  devices to offload I/O from the HyperPAV Base volumes.
  After a planned Hyperswap the target system's HyperPAV alias
  devices were brought online and attached to the system as they
  should be, but after the Hyperswap resume all I/O went through
  the Hyperpav base devices, and the HyperPAV alias devices were
  not selected to offload I/O from the HyperPAV base device.
  -----
  PROBLEM 3: Q MSS shows incorrect results with HyperPAV Aliases
             all defined in Subchannel Set 0.
  -
  Environment: Z/VM 6.3 with GDPS 3.10 SA MP 3.2.2.4
  PPRC target devices are defined in alternate subchannel set.
  HyperPAV alias devices in source and target systems are
  defined in subchannel set 0.
  -
  With HyperPAV alias devices defined in subchannel set 0 for
  both the source and target systems, the HyperPAV Alias devices
  are mistakenly counted by Query MSS adding them to the Standby
  count for Subchannel set 0 when the primary subchannel set is 0.
  The standby field together with primary SS field are what
  GDPS uses to determine whether the system is IPLed on the
  correct site and subchannel set.  Since the standby field is not
  0, the proxy sets a return code of 15 and GDPS raises an alarm
  with the following message:
  GEO060E GDPS and xDR initialization found system (XDRCSE5) being
  IPLed from wrong subchannel set.
  -----
  PROBLEM 4: Hyperswap command fails with MSHCPIOJ6429E.
  -
  Environment: z/VM 6.3, GDPS 3.10 and SA MP 3.2.2.4
  PPRC target devices are defined in alternate subchannel set.
  Primary site has HyperPAV Alias devices, secondary site
  does not.
  -
  An unplanned or planned hyperswap will fail during the SWAP
  phase with:
  MSHCPIOJ6429E <rdev> is part of an unsupported configuration for
  the hyperswap command.
  On the secondary site, since there are no HyperPAV Alias devices
  defined, the HyperPAV base devices are not marked as HyperPAV
  Base devices (there needs to be at least one HyperPAV alias
  devices present in an LSS, to mark any base device as a HyperPAV
  base device).  Hyperswap processing compares the HyperPAV base
  device status of the source devices with the non-HyperPAV base
  device status of the target devices and fails with message
  MSHCPIOJ6429E even though the enviroment is a valid enviroment.
  

Problem conclusion

• SOLUTION 1:
  Hyperswap processing was modified to not alter any TRSOURCE
  fields for any alias devices on the source or target systems
  since these devices are not actually being swapped.  This will
  prevent the ABENDSIT002 from occurring.
  -----
  SOLUTION 2:
  zVM's system attached HyperPAV Alias support was modified to
  correctly identify I/O being processed in Fast CCW translation
  that can be executed on a HyperPAV alias device.
  -----
  SOLUTION 3:
  Query MSS processing was updated to not include any Alias device
  in its counts.
  -----
  SOLUTION 4:
  Hyperswap processing was modified to accept device
  configurations where a source/target device is a
  PAV/HyperPAV Base device not marked as such and
  the associated target/source device is marked as a
  PAV/HyperPAV Base device.
  

Temporary fix

• *********
  * HIPER *
  *********
  FOR RELEASE VM/ESA CP/ESA R540 :
  PREREQ: VM64971 VM65022 VM64970 VM64939 VM64815
  CO-REQ: NONE
  IF-REQ: NONE
  FOR RELEASE VM/ESA CP/ESA R620 :
  PREREQ: VM65041 VM65335
  CO-REQ: NONE
  IF-REQ: NONE
  FOR RELEASE VM/ESA CP/ESA R630 :
  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:

  UM34139 UM34140 UM34141

Modules/Macros

• HCPHPV   HCPIOJ   HCPQPA   HCPSDV
  

Fix information

• Fixed component name

  VM CP

• Fixed component ID

  568411202

Applicable component levels

• R540 PSY UM34139

     UP13/09/30 P 1401

• R620 PSY UM34140

     UP13/09/30 P 1401

• R630 PSY UM34141

     UP13/09/30 P 1401

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.