Not sure why you're installing z/VM 5.3 when 5.4 is available for the foreseeable future (to support boxes older than z10's). But...
Gotchas: Yeah... before you format the DASD, be sure to run CPFMTXA from z/VM (you can probably do the ALLOCATE via ICKDSF from z/OS, too - but why get more systems involved?). CPFMTXA EXEC is an IBM-supplied handy z/VM front-end to ICKDSF which automatically sets all the appropriate parameters so that the dummy VTOC is written to each DASD so that they look 100% full to z/OS (preventing it from blithely writing over your minidisks, CP area, etc. Had CPFMTXA been used, you probably would not gotten into this mess, Lucy! When running CPFMTXA (or ICKDSF from z/OS), and BEFORE any formatting, be sure to run the ALLOCATE function to display the existing allocation bitmap. This will tell you how each cylinder is allocated (normally DRCT, PAGE, PARM, PERM, SPOL, or TDSK). You don't want to change anything - just be sure you document how each cylinder range is currently allocated. Whether you use CPFMTXA or z/OS, you'll need to ensure that the allocations remain (or are re-allocated) the same after the format. I'm not sure if the bit indicating the active DRCT cylinders will be affected by formatting cylinder zero of the sysres. Someone else can address that. You might want to test on a volume that is allocated as all PERM space before trying anything allocated as DRCT, PAGE, PARM, SPOL, or TDSK. Welcome to z/VM! :-) Mike Walter Hewitt Associates The opinions expressed herein are mine alone, not my employer's. "Mike Day" <y...@csi-soft.com> Sent by: "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU> 01/20/2010 03:24 PM Please respond to "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU> To IBMVM@LISTSERV.UARK.EDU cc Subject Backing up VM Volumes from z/OS We installed a new z/VM 5.3 from tape a while back and are now trying to back up the z/VM volumes using ADRDSSU from a z/OS system which runs in a different LPAR. We get a message that says "the VM-formatted volume does not have an OS-compatible VTOC". I found some instructions for using ICKDSF (see below) to format cylinder 0 which is supposed to solve the problem. I am wondering if this is the only way to handle this, or if there are other way of doing it or gotcha's I should watch out for. Thanks in advance for any information or suggestions. Mike Day Confident Software y...@csi-soft.com --------------------------------------------------------------- > Subject: Re: ADRDSSU backup of VM volume > > > I guess that 510W01 was never formatted with CPVOL. Because, CPVOL is > supposed to not only create CP's allocation bytemap, but also a VTOC telling > z/OS (& co) that the disk is full. > So, > > > 1. Assure you have no minidisk on 510W01 starting in cylinder 0 (you can > ignore the minidisk of user $ALLOC$) > 2. Run ICKDSF, press enter twice (to indicate CONSOLE as in- and output > > > 1. Link to a FULLPACK overlay on 510W01, or use DEFINE MDISK: > cp define mdisk 1234 0 end 510W01 > > 2. Verify that there is no CP area on the disk (it should not, otherwise CPVOL > would have created a dummy VTOC, but you wouldn't like to loose a CP area). > Run > cpvol list unit(1234) verify(510W01) > I expect it will tell: ICK33001I 510W01 CYLINDER ZERO NOT IN CP FORMAT. If it > would -unexpectedly- list CP areas (SPOL, PAGE, DRCT, TEMP, ... stop here. > > 3. Format cylinder 0: > cpvol format unit(1234) verify(510W01) range(0,0) ) volid(510W01) > 4. END > > 3. DETACH 1234 The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by e-mail.
