That last makes for a good question. I do not have any guests other than CMS, GCS and TPF varieties, so I have no way to trace to see if it is still a problem. The only time I encountered it was in a non-VM shop. Fortunately, we were able to wrest the disk away from the system before there was any real harm. I had the onerous task of restoring the dummy VTOC using the then state of the art IEHDASDR and SuperZap.
I cannot reproduce the situation here. The DASD Storage Management folks are adamant about not having VM volumes accessible to z/OS and vice-versa, which suits me just fine. That eliminates the only system I know of that has the potential to cause the problem. Regards, Richard Schuh > -----Original Message----- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark > Sent: Monday, September 29, 2008 1:33 PM > To: [email protected] > Subject: Re: CPFMTXA VOLUME FORMATTING QUESTION > > On Monday, 09/29/2008 at 02:06 EDT, "Schuh, Richard" <[EMAIL PROTECTED]> > wrote: > > 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. > > You need to open a PMR with the ICKDSF team on this if you're > interested in getting it fixed (assuming it is still a problem). > > Alan Altmark > z/VM Development > IBM Endicott >
