I'm having trouble understanding why an IPL'ed system's sysres and USS files are being used for cloning. I've always used a "staging" concept wherein the SMP/E target sysres and USS file(s) for each running z/OS release are * never* IPLed. This relieves a lot of issues and provides a "base", if you will, for all maintenance and cloning. What is perceived as disadvantages to using this type of "staged clone" process? I've never had any issues with it but I may just have been lucky. TIA
Guy Gardoit z/OS Systems Programming On Wed, Jan 28, 2009 at 10:18 AM, Mark Zelden <mark.zel...@zurichna.com>wrote: > On Wed, 28 Jan 2009 08:44:08 -0600, Arthur Gutowski <aguto...@ford.com> > wrote: > > >On Wed, 21 Jan 2009 08:18:44 -0600, Mark Zelden > ><mark.zel...@zurichna.com> wrote: > >[...] > >>There is no requirement for the "directory" > >>file system, but I've seen a shop's sysplex root grow because all of > >>the directories / mount points were getting created within the sysplex > >>root. This eventually led to a sysplex wide IPL in order to re-create > >>a larger sysplex root. Oh... make sure you are using a single > >>BPXPRMxx member if not already and pay attention to AUTOMOVE / > >>UNMOUNT in your MOUNT defintions. > >[...] > > > >Wow, that must have been some growth. Either that or the sysplex root was > >defined with an exceedingly small primary extent and exceedingly small or > no > >secondary extents. It's been a while since I looked, but isn't the > architected > >limit something like 123 extents or 59 volumes, whichever you hit first? > > I can't go back and look since it was a former client of mine, but a few > points: > > 1) It was probably created with the sample SYS1.SAMPLIB(BPXISYSR), > which has a space definition of 2 cyl and no secondary. Even if they > added a secondary of 2, 250 cyls isn't much. > > 2) While you can add a secondary extent with CONFIGHFS, adding volumes > requires an unmount / remount of the HFS. > > 3) A 3390-3 isn't all that big anyway. > > > > >As for AUTOMOVE / UNMOUNT, not only do you have to pay attention in terms > >of "inheritance" (filesystems mounted off "system" root and the "system" > root > >should be set the same), but it may also have implications for your > >clone/migration process. I've found the need to add an "unmount" step to > our > >clone JCL because we chose AUTOMOVE, and we have only once performed a > >sysplex-wide shutdown & IPL. > > > > Good point. That isn't part of our JCL, but it is part of our procedure to > check if the target sysres set being reused still has its unix files > mounted > (the most likely answer is "YES"). If it is, there is a rexx exec to > unmount > them. I suppose it makes sense to just add that as a step to the clone > JCL for those sysplexes. > > I can't do that in one of my other environments because we share the > sysres set across sysplexes and the cloning is done from a development > sysplex that has the maintenance unix files mounted. We have to manually > go check in the 3 sysplexes (one sandbox) that has the shared file systems > and unmount the target set's files. The sharing of resources between 2 > of those 3 sysplexes (prod/devl) goes back long before the existence of > PDSE and HFS (and the XCF / sysplex requirement for sharing) and they use > MII for integrity. Thus the "kludge". > > Mark > -- > Mark Zelden > Sr. Software and Systems Architect - z/OS Team Lead > Zurich North America / Farmers Insurance Group - ZFUS G-ITO > mailto:mark.zel...@zurichna.com > z/OS Systems Programming expert at > http://expertanswercenter.techtarget.com/ > Mark's MVS Utilities: > http://home.flash.net/~mzelden/mvsutil.html<http://home.flash.net/%7Emzelden/mvsutil.html> > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html