Only if the volume label points to somewhere that used to be a VTOC that has not been overwritten.
Unless things have changed in the last few years, the VTOC written when formatting the disk as a CPVOL does not go far enough. If the MVS DASD Storage Allocation Routine is interrupted while the checking for free space on the volume, a bit (formerly known as the DADSM Interruption Bit or DOS VTOC bit, currently known as the VSE bit, name DS4DOSBT in the F4 DSCB DSECT) is left on. The next time MVS attempts to allocate space on the volume, it will try to create proper free space records. It does this buy starting with an F5 DSCB that shows all space available on the disk. It then runs the F1 and F3 chains, allocating each described extent. Since there are no allocated extents on a CPVOL formatted disk, it shows the entire volume as being available for space allocation. There needs to be at least 1 F1 DSCB allocating the entire volume to a space-holder dataset to prevent this highly unlikely occurrence. Regards, Richard Schuh > -----Original Message----- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of Mike Walter > Sent: Monday, September 29, 2008 9:18 AM > To: [email protected] > Subject: Re: CPFMTXA VOLUME FORMATTING QUESTION > > 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!
