Are you using the 'ADMINISTRATOR' and 'CPVOLUME' parameters with ADRDSSU ? I backup my z/VM and z/Linux volumes that way.
On Thu, Jan 21, 2010 at 12:29 AM, Kris Buelens <kris.buel...@gmail.com>wrote: > It is indeed wise to list all volumes first, ICKDSF command: > CPVOL LIST UNIT(xxxx) NVFY > If it list something else than PERM, you can be sure that this dummy VTOC > is there, and that you don't need to rerun a CPVOL ALLOCATE.nor CPVOL FORMAT > RANGE(0,0) > Stronger: you only need a CPVOL FORMAT RANGE(0,0) if a CPVOL LIST reports > ... Cylinder zero not in CP FORMAT > because in all other cases, CPVOL FORMAT has been run before. > > And, beware: if you ever run CPVOL FORMAT RANGE(0,xx) or ALLOCATE on a pack > that has DRCT area(s), be sure to run DIRECTXA afterwards, because ALLOCATE > will write X'40' for DRCT cylinders, meaning "cylinder free to write a new > DIRECTORY"; DIRECTXA searches for X'40' will write X'C0' to indicate where > the active CP directory has been written > Beware2: if you'd format cilinder 0 of the VM resident, you not only need > to run ALLOCATE, but you mlust rewrite the Standalone Program Loader (SAPL), > with the SALIPL utility. > > The guide has spoken again. > > -- > Kris Buelens, > IBM Belgium, VM customer support > > 2010/1/20 Mike Walter <mike.wal...@hewitt.com> > > 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 >> >> -- Daniel Allen | Serena Software, Inc. | Senior Systems Programmer - Mainframe Services Phone: 1-800-457-3736x11241
