On Thu, Dec 3, 2009 at 1:48 AM, Scott Rohling <[email protected]>wrote:
> My experience is that unless you actually do the FORMAT of cylinder 0 -- > you 'may' end up with the VTOC issue described. We had a new volume - and > just did a LABEL on it -- and had the same issue. We then did the FORMAT > of cylinder 0 - and did not. So ever since -- my 'clip' script does a > FORMAT rather than just a LABEL - and the issue disappeared. While z/VM > seems happy enough just doing the LABEL and using it -- z/OS did not. > > ICKDSF CPVOLUME LABEL, as well as CPFMTXA ... LABEL, rewrites the volume label *only* and leaves the rest of the label record unchanged. These two commands should be used only on volumes that are already formatted. If the volume was previously initialised for z/OS with ICKDSF INIT, record 3 will be there and you may just update the label, but your VTOC will stay where it is and it can be anywhere. Ownerid surely won't be "CPVOL" and allocation map won't be there. If you later decide to make such volume CPOWNED without formatting cyl 0, but just doing ALLOCATE, results will still be unpredictable. CPVOLUME FORMAT writes six records into cyl 0, trk 0: IPL, checkpoint, label, allocation, and two VTOC records. IPL record will put the system into a wait state if this volume is IPL-ed and there's no CP; checkpoint record is all zeros and may be used by CP for a warm start; label record will have a pointer to the first VTOC record and "CPVOL" in the ownerid field, letting CP look for a checkpoint record if it wants to; allocation record will be all PERM; VTOC will look full. CPVOLUME LABEL doesn't do any of this. If you want to use the disk in VM, you should format cylinder 0. If you then copy that disk to a disk of a different size, then you may use LABEL to relabel it, ALLOCATE to update the allocation record, and REFVTOC to refresh the VTOC records with a new disk size (so that z/OS doesn't cry). Ivica
