On Tue, 11 Sep 2007 10:56:21 -0400, Hooker, Don <[EMAIL PROTECTED]>
wrote:
>And Alan, I guess I'm glad to know we're not alone. I will look up
>VM64184.
>It is for z/VM 5.2?
Both z/VM 5.2 and 5.3.
APAR Identifier ...... VM64184 Last Changed ........ 07/08/30
HUNG USER AFTER VARY ON COMMAND ISSUED TO PAV DASD
Symptom ...... WS WAIT Status ........... CLOSED PER
Severity ................... 3 Date Closed ......... 07/08/29
Component .......... 568411202 Duplicate of ........
Reported Release ......... 520 Fixed Release ............ 999
Component Name VM CP Special Notice HIPER
Current Target Date ..07/08/15 Flags RESTART/BOOT/IPL
SCP ...................
Platform ............
Status Detail: SHIPMENT - Packaged solution is available for
shipment.
PE PTF List:
PTF List:
Release 520 : UM32093 available 07/08/30 (1000 )
Release 530 : UM32096 available 07/08/30 (1000 )
Parent APAR:
Child APAR list:
ERROR DESCRIPTION:
At a certain time, some DASDs that were PAV Alias devices were
reconfigured as PAV Base devices.
This DASD reconfiguration occurred while the current IPL was
active and z/VM retained the old PAV Alias indications for the
devices that were switched to PAV Bases and hence were set as
both PAV Bases and Aliases.
These indications are defined to be mutually exclusive and since
they were both set, this caused the I/O scheduler problems with
locks and hanged the VARY command.
LOCAL FIX:
.
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: All z/VM users of Parallel Access Volumes *
* ( PAV ). *
****************************************************************
* PROBLEM DESCRIPTION: *
****************************************************************
* RECOMMENDATION: APPLY PTF *
****************************************************************
At one time on a D/T2105 controller devices 2200-22FF
were defined as D/T3390 Model 9 DASD and devices 2200-2219
and 2280-2299 were configured as PAV Bases and 221A-227F and
229A-22FF were configured as PAV Aliases. The devices were
all offline to z/VM, but the associated RDEVs were marked
as PAV Aliases or PAV Bases as appropriate.
.
Subsequently the devices were reconfigured as D/T3390 Model 3
DASDs and devices 2200-2235 and 2280-22B5 were defined as
PAV Bases and 2236-227F and 22B6-22FF were defined as PAV
Aliases.
.
For a device that switches from being a PAV Alias to a PAV Base
(Device 221A for example), the RDEV retains its old PAV Alias
setting (RDEVPVAL) and also gets marked as a PAV Base (RDEVPVBA)
when it goes through device initialization because of a VARY ON
command. These indications are defined to be mutually exclusive
and since they are both set, this causes the I/O scheduler
(HCPIQM) to get into a deadlock situation with the RDEV lock for
the device and the VARY command hangs.
PROBLEM CONCLUSION:
Device initialization code was modified to clear a PAV device's
old state when it doesn't match the new state. Specifically,
if device initialization determines that a device is a PAV Alias
device, then it will now check to see if the RDEV is currently
marked as a PAV Base device. If so, then the device's old life
(PAV Base) will be reset before indicating in the RDEV that the
device is a PAV Alias. If device initialization determines that
the device is NOT a PAV Alias device, but it is currently marked
that way in the RDEV, then the device's old life (PAV Alias)
will be reset.
If device initialization determines that a device is a PAV Base
device, then it will now check to see if the RDEV is currently
marked as a PAV Alias device. If so, then the device's old life
(PAV Alias) will be reset before indicating in the RDEV that the
device is a PAV Base.
TEMPORARY FIX:
*********
* HIPER *
*********
FOR RELEASE VM/ESA CP/ESA R520 :
PREREQ: VM63855 VM64128
CO-REQ: NONE
IF-REQ: NONE
FOR RELEASE VM/ESA CP/ESA R530 :
PREREQ: VM64222
CO-REQ: NONE
IF-REQ: NONE
COMMENTS:
MODULES/MACROS: HCPRDI HCPSDV HCPVPA
SRLS: NONE
RTN CODES:
CIRCUMVENTION:
MESSAGE TO SUBMITTER:
