Thanks, Alan!
Will the new function define the DASD size in the VTOC based on the size of the real (emulated, sigh) DASD, or the MDISK size that a virtual machine running ICKDSF sees when the command is issued? This gets back to Jeff's report that linking to an MDISK defined to map only cylinder zero of the real (emulated) DASD resulted in a VTOC describing a one-cylinder 3390 (what's that, a model 3390-.1113?).
Mike Walter
Hewitt Associates
The opinions expressed herein are mine alone, not my employer's.
| "Alan Altmark"
<[EMAIL PROTECTED]>
Sent by: "VM/ESA and z/VM Discussions" <[email protected]> 03/01/2006 11:41 PM
|
|
On Wednesday, 03/01/2006 at 11:17 EST, "A. Harry Williams"
<[EMAIL PROTECTED]> wrote:
> I disagree. LIST is by definition a R/O type function, and
> doing any sort of write is BAD. Even IDCAMS doesn't do that.
> And to do so silently under the covers if a certain hardware
> switch is flipped is mindboggling. It is also violates the
> principal of least surprises. DSF never does anything without
> asking, or being told to not ask.
Yes, we and DSF ultimately came to the same conclusion this evening. The
offending PTF will be marked PE and a new APAR will be created to add a
new "CPVOL REFVTOC" (or something like it) to cause the VTOC to be
rewritten to match the size of the disk and remove all mention of
alternate cylinders.
And I have the answer to why the alternate cylinder count is so dang
important: DFSMSdss on MVS will include them in the total cylinder count,
resulting in a mismatch between the number of cylinders in the VTOC
(primary + alternate) and the number of cylinders returned by the device.
That mismatch gives DSS users a warning every time about the mismatch. A
cry went out across the land....
But rather than fix DSS's boneheaded view of the universe and simply
ignore the now-irrelevant alternate cylinder count, it was decided that
the correct solution was to fix-up the VTOC instead. That resulted in
REFORMAT REFVTOC on DSF/MVS. So now VM will have the same function (e.g.
CPVOL REFVTOC) and fixing the problem will be left up to the sysprog. Now
if you get into trouble with this it won't be *our* fault!! :-)
Thanks to Jeff for bringing it to our attention. The DSF folks learned
some things along the way and I got to stroll down Alternate Cylinder
Memory Lane. A special thanks to Steve Wilkins, my colleague, for knowing
exactly who to call in DSF Land and for helping with some experimentation.
I hope I to see many of you soon in Seattle for SHARE.
Alan Altmark
z/VM Development
IBM Endicott
The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited.
