You can DEDICATE by label rather than by real address. But I still don't like Linux having cyl 0 :)
Marcy "This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation." -----Original Message----- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of David Boyes Sent: Wednesday, March 24, 2010 11:20 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] initializing z/Linux disks On 3/24/10 1:53 PM, "Martin, Terry R. (CMS/CTR) (CTR)" <terry.mar...@cms.hhs.gov> wrote: > > Hi > > I have a question. What I have been doing up to this point for a new z/Linux > guest build is, not necessarily in this order and does not necessarily include > all steps but, > > Crave out the DASD for the z/Linux guest > > Init the DASD using CPFMTXA putting a label on the disk > > Setting up the Directory entry for the new guest, which includes specifying > the MDISK for all of the DASD for the guest. Unless you are giving the guest the real cyl 0, you need to do the format for at least real cyl 0 with ICKDSF (what CPFMTXA runs under the covers) to put a real volume id on the pack. I find that even if you are giving the guest the real cyl 0, the extra step of running DSF on the entire real volume eliminates any past uses that may confuse system operation later on (think about what would happen if you "accidentally" gave a guest what used to be a VM paging pack, and forgot to clip the allocation bitmap to remove the page space. Bad Things Ensue. Kickstart and VM paging space are NOT compatible. Things Go Boom. Trust Me.) So, if you are giving the guest the full physical volume, you don't HAVE to do the DSF run, but it's an extra safety measure that it doesn't cost much to do, and you'll be grateful for if you ever need it. > If not I assume then I would replace the MDISK statements in the Directory > entry with DEDICATE statements for each one of the DISKS. We do not share DASD > between guests here so what is defined to the guest belongs to that guest > only. Is there anything to be aware of by changing to DEDICATE statements from > MDISK statements? DEDICATEs tie you very firmly to specific physical configurations. Does your DR configuration have exactly the same device addresses for real devices? If not, then you'll have to update the directory when you move to to DR vs just changing volume labels which aren't bound to specific device addresses. You can do search/replace in both cases, but it's a lot easier to relabel packs when you restore your stuff on them than have to screw around with addresses, especially if it's a REAL emergency and you may not get your normal DR configuration because of a sudden influx of companies needing DR. > My only concern is with the DFDSS backups that I do on the z/OS for the > guests. I am not sure if it matters or not to DFDSS whether the pack was > initialized via CPFMTXA or z/Linux during the kick start process? It shouldn't, but why introduce another variable? CP and z/OS have been getting along well for decades now. It's a one-time step, and it doesn't take that much longer. You can also shortcut the process (if you have Flashcopy) by keeping a blank formatted volume around, flashcopy it to the new disks, and then just run DSF on cyl 0 to relabel the pack. That's almost instantaneous, and you get the best of both worlds. -- db
