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
