ICKDSF R17 CPVOL LIST - R/W DASD Required

[Jeff Gribbin, EDS]

We regularly run CPVOL LIST functions against all our VM DASD as part of
our DR suite - the output from the CPVOL LIST being used to generate CMS
files containing the ICKDSF CPVOL FORMAT / ALLOCATE statements that we'll
need for recovery at DR.

This weekend the server that does this job fell over. ICKDSF R17 had been
installed last week (as part of move to 5.2) and it turns out that it
requires the disks to be linked R/W - even though it's just a LIST that's
being asked for.

Apparently the culprit is PTF UK02944 which was introduced with R17 and
which is trying to quietly fix "VTOCS" that were broken by a previous
ICKDSF problem. (I'm a bit vague - I found the documentation thread rather
hard to follow.)

Anyway, the upshot is that (at least sometimes) ICKDSF R17 running CPVOL
LIST commands will require disks to be linked R/W and will require an
additional response ("Reply, 'U' to alter, else, 'T'"). Sooo, if you have
an automated process that uses CPVOL LIST ... beware !!!

I'm told that this is working as designed. Anybody else feel that we
should fight this? Anybody from IBM able to (please) explain to me why I'm
wrong in thinking that we SHOULD fight this?

Regards
Jeff

[Schuh, Richard]

Unfortunately, nothing is even mentioned in the help files. I guess that leaves it up to the originator to say whatever is convenient about the design. Remember the '80s when the first words out of the developer's mouth were WAD? They had to be convinced that WAD was sometimes BAD, and that BAD should be treated as a defect.

If you have VPARS on the system you can link the disk in R/O mode at one of the trapped addresses, VPOPEN the VPARS database and then do the ICKDSF. With VPARS in the picture, the device will appear to be R/W when, in fact, it isn't.

Regards,
Richard Schuh

-----Original Message-----
From: VM/ESA and z/VM Discussions [mailto:VMESA-***@LISTSERV.UARK.EDU] On Behalf Of Jeff Gribbin, EDS
Sent: Monday, February 27, 2006 7:19 AM
To: VMESA-***@LISTSERV.UARK.EDU
Subject: ICKDSF R17 CPVOL LIST - R/W DASD Required

We regularly run CPVOL LIST functions against all our VM DASD as part of =

our DR suite - the output from the CPVOL LIST being used to generate CMS =

files containing the ICKDSF CPVOL FORMAT / ALLOCATE statements that we'll=

need for recovery at DR.

This weekend the server that does this job fell over. ICKDSF R17 had been=

installed last week (as part of move to 5.2) and it turns out that it
requires the disks to be linked R/W - even though it's just a LIST that'=
s
being asked for.

Apparently the culprit is PTF UK02944 which was introduced with R17 and =

which is trying to quietly fix "VTOCS" that were broken by a previous
ICKDSF problem. (I'm a bit vague - I found the documentation thread rathe=
r
hard to follow.)

Anyway, the upshot is that (at least sometimes) ICKDSF R17 running CPVOL =

LIST commands will require disks to be linked R/W and will require an
additional response ("Reply, 'U' to alter, else, 'T'"). Sooo, if you have=

an automated process that uses CPVOL LIST ... beware !!!

I'm told that this is working as designed. Anybody else feel that we
should fight this? Anybody from IBM able to (please) explain to me why I'=
m
wrong in thinking that we SHOULD fight this?

Regards
Jeff

[Hans Rempel]

Very interesting Jeff. I too use CPVOL list command to extra volume
information used to build my DR files for fast recover. I'm in the process
of bringing up z/VM 5.2 but have not run that exec.

LIST should never need write to volume let alone modify the volume data
info. I don't like this.

Hans

-----Original Message-----
From: VM/ESA and z/VM Discussions [mailto:VMESA-***@LISTSERV.UARK.EDU] On
Behalf Of Jeff Gribbin, EDS
Sent: February 27, 2006 10:19 AM
To: VMESA-***@LISTSERV.UARK.EDU
Subject: ICKDSF R17 CPVOL LIST - R/W DASD Required

We regularly run CPVOL LIST functions against all our VM DASD as part of =

our DR suite - the output from the CPVOL LIST being used to generate CMS =

files containing the ICKDSF CPVOL FORMAT / ALLOCATE statements that we'll=

need for recovery at DR.

This weekend the server that does this job fell over. ICKDSF R17 had been=

installed last week (as part of move to 5.2) and it turns out that it
requires the disks to be linked R/W - even though it's just a LIST that'=
s
being asked for.

Apparently the culprit is PTF UK02944 which was introduced with R17 and =

which is trying to quietly fix "VTOCS" that were broken by a previous
ICKDSF problem. (I'm a bit vague - I found the documentation thread rathe=
r
hard to follow.)

Anyway, the upshot is that (at least sometimes) ICKDSF R17 running CPVOL =

LIST commands will require disks to be linked R/W and will require an
additional response ("Reply, 'U' to alter, else, 'T'"). Sooo, if you have=

an automated process that uses CPVOL LIST ... beware !!!

I'm told that this is working as designed. Anybody else feel that we
should fight this? Anybody from IBM able to (please) explain to me why I'=
m
wrong in thinking that we SHOULD fight this?

Regards
Jeff
[This E-mail scanned for viruses]

[David Boyes]

Post by Jeff Gribbin, EDS
installed last week (as part of move to 5.2) and it turns out
that it requires the disks to be linked R/W - even though
it's just a LIST that'= s being asked for.

Broken. There's no reason to need write access for LIST, and there is
DEFINITELY no reason for DSF to be updating disks without being
explicitly asked to do so.

Post by Jeff Gribbin, EDS
I'm told that this is working as designed. Anybody else feel
that we should fight this? Anybody from IBM able to (please)
explain to me why I'= m wrong in thinking that we SHOULD fight this?

You're not wrong.

[David Boyes]

Of course, if only one person calls the Support Center to
compl....er uh...report the problem, then everyone else must
be ok with the behavior, if you get my drift.
I say this only because when one sees a malfing program, one
calls it in.

One did. 8-)

One does not sit and blink uncomprehendingly at it, howl at
the moon (ok, some of you do - you know who you are), pound
one's fist on the table in anger, or storm the castle with
pitchforks and torches.

Hey, I'm an part-time ogre -- just ask the people who work for me...8-).
Pitchforks and torches are in the contract. Besides, *after* the
pitchforks and torches, you own the castle...8-)

Hic jacent Priscius.

-- db

[Adam Thornton]

Post by David Boyes
Hic jacent Priscius.
-- db

Antiqui colant antiquum dierum

Also, shouldn't it be "hic jacet," unless Priscius had multiple
personality disorder or something?

Adam

[Daniel P. Martin]

Must be either too much or too little caffeine. I'm struck by visions
of David skulking about the battlements, all Gollum-like, muttering "My
Priscius..." while Alan is circling the moat on horseback, dressed up
like Howdy Doody, singing "Oh give me a home, with a moat of my own..."

Or maybe somebody has been slipping Adam's special blend of cough syrup
into my coffee.

Ahem. None of which has much of anything to do with rude behavior from
ICKDSF...

-dan.

Post by Adam Thornton

Post by David Boyes
Hic jacent Priscius.
-- db

Antiqui colant antiquum dierum

Also, shouldn't it be "hic jacet," unless Priscius had multiple
personality disorder or something?
Adam

[Adam Thornton]

Post by Daniel P. Martin
Must be either too much or too little caffeine. I'm struck by
visions of David skulking about the battlements, all Gollum-like,
muttering "My Priscius..." while Alan is circling the moat on
horseback, dressed up like Howdy Doody, singing "Oh give me a home,
with a moat of my own..."
Or maybe somebody has been slipping Adam's special blend of cough
syrup into my coffee.

In the immortal words of Wavy Gravy, "the brown acid is not,
specifically, too good."

Adam

[Chris Langford]

Post by David Boyes
Hic jacent Priscius.
-- db

Antiqui colant antiquum dierum

--
Chris Langford,
Cestrian Software:
Consulting services for: VM, VSE, MVS, z/VM, z/OS, OS/2, P/3x0 etc.

z/FM - A toolbox for VM & MVS at http://zfm.cestrian.com
Deva Woodcrafting:
Furniture creation, House remodeling, Wagon restoration etc.

[Huegel, Thomas]

And a damsel in distress, there must be a damsel in distress. (maybe ICKDSF
will do)

-----Original Message-----
From: Alan Altmark [mailto:***@us.ibm.com]
Sent: Tuesday, February 28, 2006 9:22 AM
To: VMESA-***@LISTSERV.UARK.EDU
Subject: Re: ICKDSF R17 CPVOL LIST - R/W DASD Required

Post by David Boyes
Hey, I'm an part-time ogre -- just ask the people who work for me...8-).
Pitchforks and torches are in the contract. Besides, *after* the
pitchforks and torches, you own the castle...8-)

Ooooooh, yeah! A moat! A moat of my very own! With monsters! Secret
passageways, dungeons, screaming. (sigh) Kinda makes me miss the ol'
homestead (sniff) ...

Post by David Boyes
Hic jacent Priscius.

Now there's no reason to be calling me a "hick". I may not be from The
Big City, but I'm not completely iggernant. (And from the other words, I
think one of the cats jumped on your keyboard.)

C.


__________________________________________________________________
<< ella for Spam Control >> has removed VSE-List messages and set aside
VM-List for me
You can use it too - and it's FREE! http://www.ellaforspam.com

[Adam Thornton]

Post by Huegel, Thomas
And a damsel in distress, there must be a damsel in distress.
(maybe ICKDSF will do)

If you're seeing ICKDSF as a damsel, whether in distress or not,
you're at least as deluded as those sailors who thought manatees were
lissome mermaids. I recommend some serious shore leave.

Adam

[David Boyes]

Post by Adam Thornton

Post by David Boyes
Hic jacent Priscius.

Antiqui colant antiquum dierum

Also, shouldn't it be "hic jacet," unless Priscius had
multiple personality disorder or something?

I'd think so. At least, the way August Derleth describes him...8-)

(Isn't a decent humanities education fun?)

-- db

[Jeff Gribbin, EDS]

Folks,
Great fun, but back to the topic <sigh>.

I am told that ICKDSF Development is saying that R17's behaviour is
perfectly reasonable and predictable and are currently refusing to budge.

If you feel that ICKDSF is, "being rude" then, please, CALL IT IN.
Development won't consider fixing it all the time it's just the current
handful of customers who're complaining.

Specifically, I'm asking for ICKDSF CPVOL LIST to always work when
presented with a R/O disk - this will give me back my Disaster Recovery
procedures. I have also expressed concern that when it's presented with a
R/W disk it's updating the VTOC, "under the covers" but, frankly, as my
disks never need to go anywhere near a zOS system, this is a much lesser
concern from where I'm sitting and, to get the big worry fixed, I'll play
along if necessary.

Development are reportedly taking the attitude, "You only have to do it
onece, so what's the problem?" I have asked my man to point out to them
that it's quite a big problem when one is faced with several hundred
volumes and has to request Security changes to gain R/W access to Cylinder
0. There's also no guarantee that a volume won't be missed (or re-
formatted with an earlier version of ICKDSF) so, all the time this
behaviour is possible, my procedures are no longer bullet proof. The word
back, however, is that they're not listening.

Please, help me make 'em listen. Raise your own PMR today.

With thanks in anticipation.
Jeff

(BTW Great side-chat - The images it invokes make the pain generated by
this problem almost-worthwhile <g>.)

[Rob van der Heij]

Post by Jeff Gribbin, EDS
I am told that ICKDSF Development is saying that R17's behaviour is
perfectly reasonable and predictable and are currently refusing to budge.

I can accept that some developer did not have enough peer review to
prevent him from being "helpful" but I am surprised to see them dig
their heels in the sand. You're probably right that it takes a bit
more PMR's to help them understand the process.

We're probably too nice an audience to nail them to the fence, like it
happens in other areas:
http://www.theregister.co.uk/2003/11/07/help_my_belkin_router/
Belkin made their router direct you to their advertising page rather
than where you wanted to go, just to be helpful to point out there
were neat features in the router that you had not enabled...

--
Rob van der Heij
Velocity Software, Inc

[McKown, John]

Oh,

Post by Schuh, Richard
-----Original Message-----
From: VM/ESA and z/VM Discussions
Sent: Wednesday, March 01, 2006 10:48 AM
Subject: Re: ICKDSF R17 CPVOL LIST - R/W DASD Required
Where is Lyn Hadley when you need him? Oh, well. He probably
would not be able to budge developers from that alternate
universe. That behavior is perfectly reasonable in a universe
where there is only one operating system.

They must be hanging with the z/OS people. Same attitude from them.
<snip>

Post by Schuh, Richard
Regards,
Richard Schuh

--
John McKown
Senior Systems Programmer
UICI Insurance Center
Information Technology

This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and its
content is protected by law. If you are not the intended recipient, you
should delete this message and are hereby notified that any disclosure,
copying, or distribution of this transmission, or taking any action
based on it, is strictly prohibited.

[Schuh, Richard]

Where is Lyn Hadley when you need him? Oh, well. He probably would not be able to budge developers from that alternate universe. That behavior is perfectly reasonable in a universe where there is only one operating system.

I have not run into this as yet, but I think it perfectly reasonable to require R/W access only when it is necessary to write on the disk. I also think it proper to have R./O access wherever possible to prevent accidental or unexpected writes from unknown sources (such as ICKDSF).


Regards,
Richard Schuh

-----Original Message-----
From: VM/ESA and z/VM Discussions [mailto:VMESA-***@LISTSERV.UARK.EDU] On Behalf Of Jeff Gribbin, EDS
Sent: Wednesday, March 01, 2006 4:08 AM
To: VMESA-***@LISTSERV.UARK.EDU
Subject: Re: ICKDSF R17 CPVOL LIST - R/W DASD Required

Folks,
Great fun, but back to the topic <sigh>.

I am told that ICKDSF Development is saying that R17's behaviour is
perfectly reasonable and predictable and are currently refusing to budge.=


If you feel that ICKDSF is, "being rude" then, please, CALL IT IN.
Development won't consider fixing it all the time it's just the current =

handful of customers who're complaining.

Specifically, I'm asking for ICKDSF CPVOL LIST to always work when
presented with a R/O disk - this will give me back my Disaster Recovery =

procedures. I have also expressed concern that when it's presented with a=

R/W disk it's updating the VTOC, "under the covers" but, frankly, as my =

disks never need to go anywhere near a zOS system, this is a much lesser =

concern from where I'm sitting and, to get the big worry fixed, I'll play=

along if necessary.

Development are reportedly taking the attitude, "You only have to do it =

onece, so what's the problem?" I have asked my man to point out to them =

that it's quite a big problem when one is faced with several hundred
volumes and has to request Security changes to gain R/W access to Cylinde=
r
0. There's also no guarantee that a volume won't be missed (or re-
formatted with an earlier version of ICKDSF) so, all the time this
behaviour is possible, my procedures are no longer bullet proof. The word=

back, however, is that they're not listening.

Please, help me make 'em listen. Raise your own PMR today.

With thanks in anticipation.
Jeff

(BTW Great side-chat - The images it invokes make the pain generated by =

this problem almost-worthwhile <g>.)

[Paul Hanrahan]

There is only one operating system. VM.

-----Original Message-----
From: VM/ESA and z/VM Discussions [mailto:VMESA-***@LISTSERV.UARK.EDU] On
Behalf Of Schuh, Richard
Sent: Wednesday, March 01, 2006 11:48 AM
To: VMESA-***@LISTSERV.UARK.EDU
Subject: Re: ICKDSF R17 CPVOL LIST - R/W DASD Required


Where is Lyn Hadley when you need him? Oh, well. He probably would not be
able to budge developers from that alternate universe. That behavior is
perfectly reasonable in a universe where there is only one operating system.

I have not run into this as yet, but I think it perfectly reasonable to
require R/W access only when it is necessary to write on the disk. I also
think it proper to have R./O access wherever possible to prevent accidental
or unexpected writes from unknown sources (such as ICKDSF).


Regards,
Richard Schuh

-----Original Message-----
From: VM/ESA and z/VM Discussions [mailto:VMESA-***@LISTSERV.UARK.EDU] On
Behalf Of Jeff Gribbin, EDS
Sent: Wednesday, March 01, 2006 4:08 AM
To: VMESA-***@LISTSERV.UARK.EDU
Subject: Re: ICKDSF R17 CPVOL LIST - R/W DASD Required

Folks,
Great fun, but back to the topic <sigh>.

I am told that ICKDSF Development is saying that R17's behaviour is
perfectly reasonable and predictable and are currently refusing to budge.=


If you feel that ICKDSF is, "being rude" then, please, CALL IT IN.
Development won't consider fixing it all the time it's just the current =

handful of customers who're complaining.

Specifically, I'm asking for ICKDSF CPVOL LIST to always work when
presented with a R/O disk - this will give me back my Disaster Recovery =

procedures. I have also expressed concern that when it's presented with a=

R/W disk it's updating the VTOC, "under the covers" but, frankly, as my =

disks never need to go anywhere near a zOS system, this is a much lesser =

concern from where I'm sitting and, to get the big worry fixed, I'll play=

along if necessary.

Development are reportedly taking the attitude, "You only have to do it =

onece, so what's the problem?" I have asked my man to point out to them =

that it's quite a big problem when one is faced with several hundred
volumes and has to request Security changes to gain R/W access to Cylinde= r

0. There's also no guarantee that a volume won't be missed (or re- formatted
with an earlier version of ICKDSF) so, all the time this
behaviour is possible, my procedures are no longer bullet proof. The word=

back, however, is that they're not listening.

Please, help me make 'em listen. Raise your own PMR today.

With thanks in anticipation.
Jeff

(BTW Great side-chat - The images it invokes make the pain generated by =

this problem almost-worthwhile <g>.)

[Jeff Gribbin, EDS]

Folks, this is even more broken than I originally realised ...

I was getting some weird behaviour where it'd want write access to disks
that I'd already, "done". It happened a couple of times but I put it down
to just too many years in front of the keyboard. Then, driving home, it
suddently dawned on me what's happening ...

They're fixing the VTOC to match the true size of the disk.

When I ran R17-plus-PTF against my disks with the disks linked R/W, in
order to, "fix things" for my #1 target system, I used full-pack minidisks.

When I reran the CPVOL LIST commands I linked (R/O) to the minidisks in
£ALLOC£ - and, as tradition demands, these are one-cylinder minidisks at
location zero.

Dear old ICKDSF is saying, "Oops! the VTOC says he's got thousands of
cylinders, but he's only got one - I'd better rewrite it!"

So, anytime you do a CPVOL LIST using ICKDSF-plus-PTF you'd better have
exactly the same size minidisk as you had last time you ran it, or it'll
demand write access so's it can play with the VTOC!

<sigh>

Keep making the calls folks - I originally thought this was just a, "nit" -
but if it's allowed to stand as-is then I now see that it has the
potential to turn into a serious and perennial thorn in our collective
sides.

Oh well, it's teatime here, so TTFN.

Regards
Jeff

[A. Harry Williams]

On Wednesday, 03/01/2006 at 12:00 CST, "Jeff Gribbin, EDS"
While CPVOL LIST is a read-type operation, having the disk linked R/W
gives implicit permission for it to change the volume. It isn't
unreasonable, I think, for DSF to take the opportunity to fix the VTOC
w.r.t. alternate cylinders if the count is non-zero. Now, changing the

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.

/ahw

[Jeff Gribbin, EDS]

Amen - and SPECIAL thanks to Alan for both understanding the problem and
engaging in constructive dialogue with the right people. We've all learned
something, so the exercise has been worthwhile.

Chuckie - Thanks also for your offer of intervention but I'm sure that
you'll understand when I say I'm relieved that we didn't actually have to
ask Alan to let you off your leash ... memories of schoolboy Latin (I only
ever did one year) was something that I did NOT expect when I started this
thread!

Again, thanks to all who took part.

Regards,
Jeff

"Progress - That which is achieved when the understanding of what NEEDS to
be done comes together with the capability to GET things done."

[David Boyes]

While CPVOL LIST is a read-type operation, having the disk
linked R/W gives implicit permission for it to change the
volume.

I strongly disagree. Unless explicitly asked, no IBM utility should EVER
update disks, regardless of link mode. Nowhere in the DSF documentation
does it ever refer to updating data when using CPVOL LIST. All the
references are to "read".

It isn't unreasonable, I think, for DSF to take the
opportunity to fix the VTOC w.r.t. alternate cylinders if the
count is non-zero.

It's reasonable for it to ASK whether it can fix it. Just "going ahead
and fixing it" without asking is not at all reasonable, unless you're
signing up to explain it to customer security people at your expense. I
don't think you want that responsibility.

[Schuh, Richard]

Good man, Alan. Now we don't have to call Len out of retirement ;-)

Regards,
Richard Schuh

-----Original Message-----
From: VM/ESA and z/VM Discussions [mailto:VMESA-***@LISTSERV.UARK.EDU] On Behalf Of Alan Altmark
Sent: Wednesday, March 01, 2006 9:42 PM
To: VMESA-***@LISTSERV.UARK.EDU
Subject: Re: ICKDSF R17 CPVOL LIST - R/W DASD Required

On Wednesday, 03/01/2006 at 11:17 EST, "A. Harry Williams"

Post by A. Harry Williams
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