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:[EMAIL PROTECTED] On Behalf Of Jeff Gribbin, EDS Sent: Monday, February 27, 2006 7:19 AM To: [email protected] 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
