Hi JR,
I'm a little confused by your description of the experiences you've been
having with PAV, so have interjected my commentary on the matter below in
hopes of understanding it better...
Imler, Steven J wrote on 07/03/2008 09:32:13 PM:
> Well ... for me ... it's not an issue of what benefit having a PAV
> alias(es) for a given volume might yield. It's a question of support
> and toleration (for example, will VM:Backup or HiDRO back the BASE up
> and erroneously back the potential PAV alias(es) too?).
>
> So, up until recently (6 months ago or so [we did a huge DASD
> migration]), each time our storage group got a new disk array (IBM or
> Hitachi, whatever), they would hard-code PAV alias addresses into the
> "DASD subsystem" ... because z/OS needed that. When this was done, z/VM
> 5.3 could "see and use" the PAV alias(es) (for non-z/OS volumes too).
>
The only hard-coded PAV-aliases I'm aware of are in the "classic" PAV
mode, where a single base subchannel can have zero or more aliases. These
devices and their respectively subchannels are all viewed independently of
one another as viewed by the host OS, regardless of whether it's z/OS or
z/VM or whoever. What the OS does with those devices is clearly a
different matter, but from a simplistic stance of whether z/VM is able to
"see and use" them, this is all true.
> However, now, z/OS does not require that PAV alias(es) be defined to the
> disk array (hard coded in the DASD subsystem) with the newer DASD
> subsystems ... z/OS (I think via WLM) can *dynamically define* PAV
> aliases to alleviate I/O contention ... the PAV aliases do not need to
> be pre-defined or hard-coded in the DASD subsystem/configuration. (This
> is why our storage group no longer defines the PAV alias addresses to
> the DASD subsystem ... and won't for z/VM.)
>
If the DASD is still in the "classic" PAV mode, then you're technically
correct that z/OS (via WLM) can "create" a PAV alias to a device that
needs one. But it does so by stealing an alias from a comparatively idle
base device, while still maintaining a static association of aliases
mapping to particular bases within the DASD subsystem. As an example, if
you were to go back to the DASD subsystem management tool, you might note
that Alias 816F (corresponding LSS/UA rules apply) is now associated with
base 8114 instead of 810F as it was originally configured.
Now if you're referring to HyperPAV (which we added support for in z/VM
5.3), the aforementioned association is dissolved from the operating
system's point of view, and any base that needs an alias will pick one out
of a pool associated with the LSS on a per-IO basis. The association is
still there in the DASD subsystem, lest the CU be put back into "classic"
PAV mode (see the z/VM SET CU command), but the different OS's aren't
going to see it unless that has happened. Regardless, the devices are
still defined and should still be visible to z/VM, they just will not be
capable of pointing to anything useful within the DASD until its used.
> Please correct me if I'm wrong, but z/VM still requires the PAV
> alias(es) to be hard-coded/pre-defined to the DASD subsystem ...
> HyperPAV support or whatever in z/VM. Otherwise, z/VM can not support
> PAV aliases. This is what we've experienced at our site. If there's
> something we are missing in the z/VM support, please let me know.
>
> Thanks,
> JR
>
Having said all that, I'm still having a hard time getting my head around
the description of your experience. Perhaps I'm just missing something
obvious, but from what I can gather, I don't know why it wouldn't work. If
you're having problems with it, get a PMR opened with us. If we're just
talking different languages (entirely possible, I've been told I don't
speak English), contact me off list as it suggests there are opportunities
in the links that Bill provided the other day...
Regards,
Eric
Eric Farman
z/VM I/O Development
IBM Endicott, NY
