What about the dummy VTOC that CPFMTXA (or ICKDSF's CPVOL command) places on cylinder zero? Without that dummy VTOC, which makes it appear to Other Systems that there is no space left on the DASD, they can and **WILL* write on it!
From: http://listserv.uark.edu/scripts/wa.exe?A2=ind9709&L=IBMVM&P=R14050&I=-3&X=72B31F0083433ED14B&Y=mike.walter%40hewitt.com ---<snip>--- It was the Monday, the VM/SP 1 system was up and running with almost 30 users (just about the high end way back then) when it crashed. After it came up I loaded the dump and just had a chance to see the registers - which looked very strange, when it crashed again. After it came up, checked the dump again and registers 1 and 2 contained: C3C8C5C5 E2C54B40. A rather unusual set of addresses in pre-XA days, and pretty unlikely even now. It took only moments for the light to come on; R1 and R2 contained EBCDIC for 'CHEESE. '! I loaded up the second dump and just had time to see another set of registers (not sure if it was R1-R2 or R11-R12) which contained D9C5D7D6 D9E34040. That translated to 'REPORT '. For some reason something clicked and I ran down to the data center to check. Sure enough, one of our just-added page volumes was mounted as 'PUBLIC' on one of the MVS systems. Another group was responsible for running CPFMT and adding new DASD to the system. We usually double-checked their work, but this case missed checking the new page volume. It had been INITed, but they had neglected to run CPFMT to place the dummy VTOC on it. So to MVS it looked empty, while VM paged out to that volume, MVS wrote temporary datasets on it, which VM paged in and tried to load as executable instructions. I still refer to this as the time the system crashed because there was CHEESE in the registers (sounds like a hardware problem)! ---<snip>--- I think we were the only VM customer to ever crash a VM system because we had cheese in our registers. It gummed up the works pretty well! ;-0 We were fortunate that the data loaded back from DASD was fairly obvious. It could have been much more difficult to resolve. Moral: ALWAYS format VM DASD with CPVOL - at __LEAST__ cylinder zero. "Trust, but verify"! Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. "Schuh, Richard" <[EMAIL PROTECTED]> Sent by: "The IBM z/VM Operating System" <[email protected]> 09/29/2008 10:33 AM Please respond to "The IBM z/VM Operating System" <[email protected]> To [email protected] cc Subject Re: CPFMTXA VOLUME FORMATTING QUESTION A disk containing no system areas need not be formatted by CPFMTXA. The only thing really needed is the volume label. That said, yes, you can format only cylinder 0. "CPFMTXA dev volser 0 0" will do it. Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Howard Rifkind Sent: Monday, September 29, 2008 8:25 AM To: [email protected] Subject: CPFMTXA VOLUME FORMATTING QUESTION Hello all, I have a new DASD address which has to be added to z/VM 5.3 which was previously formatted with a z/OS format. I didn't do a CPFMTXA format. I attached the volume to system and DDR'ed a few minidisks over to the new volume. So, cylinder 0 of the new volume is not in CP format. The copied minidisks are O.K and I would hate to do the copies again. Is there anyway to CPFMTXA just cylinder 0 and then allocate the entire volume as PERM without loosing the copied minidisks? Thanks. _____________ LEGAL NOTICE Unless expressly stated otherwise, this message is confidential and may be privileged. It is intended for the addressee(s) only. Access to this E-mail by anyone else is unauthorized. If you are not an addressee, any disclosure or copying of the contents of this E-mail or any action taken (or not taken) in reliance on it is unauthorized and may be unlawful. If you are not an addressee, please inform the sender immediately, then delete this message and empty from your trash. 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. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by e-mail.
