You could call it a documentation error of omission and fix it that way
:) It would be (a) easier, and (b) backward compatible.

Regards, 
Richard Schuh 

 

> -----Original Message-----
> From: The IBM z/VM Operating System 
> [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark
> Sent: Friday, November 14, 2008 3:13 PM
> To: [email protected]
> Subject: Re: FW: Risk of Adding a Paging Volume
> 
> On Friday, 11/14/2008 at 01:07 EST, "Schuh, Richard" <[EMAIL PROTECTED]>
> wrote:
> > Actually, it is record 3 that contains the volume label. It and 
> > records 1, and 2 are 80 byte records.
> 
> Technically, the VOL1 label standard permits the label to 
> exceed 80 characters, up to the record length, but CPVOLs 
> only use 80 bytes.
> 
> > 1 and 2 are the IPL1 and IPL2 records if the volume can be IPLed. 
> > Records 4 and 5 are the VTOC that is written to prevent 
> other systems 
> > from corrupting the volume.
> 
> [Notation below is "cylinder/head(track)/record".]
> 
> 0/0/4 contains the allocation map.  It is able to go there 
> because the label (0/0/3) points to the record (on 0/0) that 
> contains the VTOC. CPVOLs (i.e. CPFMTXA) place the VTOC on 0/0/5.
> 
> The VTOC contains two extents:
> 1. The extent of the VTOC itself.  This is where it gets 
> clever.  The label says it starts at 0/0/5, but VTOCs are 
> measured in *tracks*, not *records*.  For CPVOLs, the VTOC 
> consumes all of cyl 0, track 0.  This protects all the 
> records on track 0 from the depredations of z/OS (assuming it 
> was so inclined).
> 
> 2. The list of available extents.  Being oh so clever again, 
> the list is empty.
> 
> If anyone wants to read more about VTOCs, and DSCBs, go look 
> at the z/OS DFSMSdfp Advanced Services book, chapter 1.
> 
> > The system has, for a long time, protected the first records of 
> > cylinder 0, maybe all of 0/0/0, and used the rest of the 
> cylinder for 
> > paging or spooling if cylinder 0 is so allocated.
> 
> Note that this protection does not extend to T-disk.  If you 
> allocate cyl 0 as TDSK, CP will happily (for the moment) hand 
> real cyl 0 to a guest. So the rule is "don't do that".  We 
> plan to fix it in a future release.
> 
> Alan Altmark
> z/VM Development
> IBM Endicott
> 

Reply via email to