Eric,
Thanks for this information ... I'll review it internally with our
systems guys (maybe the SET CU was what we missed).
If it seems we still have issues contradicting the behavior you've
outlined below I will get in touch with you/IBM to iron this out.
Thanks again,
JR
JR (Steven) Imler
CA
Senior Software Engineer
Tel: +1 703 708 3479
Fax: +1 703 708 3267
[EMAIL PROTECTED]
________________________________
From: The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] On Behalf Of Eric R Farman
Sent: Monday, July 07, 2008 08:55 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: z/VM 5.3 and PAV
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
