If DFSMS uses the SFS for read/only activity. I would be tempted to give it its own small filepool and DDR DUMP it once. There would be no need to go to the pain of first creating a new filepool into which I could then do a FILEPOOL RELOAD. Even if there is R/W activity in the filepool, it would not take much time to redo the DDR as part of the periodic backup process. DFSMS would have to be paused for only a very short time.
Regards, Richard Schuh > -----Original Message----- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of Romanowski, John (OFT) > Sent: Friday, March 28, 2008 10:57 AM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: DR refresh of active SFS > > Thomas and Marcy, > I agree 100%. As Marcy said " there are plenty of VM newbies > around here these days who shouldn't have to understand all > the care and feeding of SFS in order to backup and restore > their systems or to configure their tape libraries for that matter." > > I minimize? the pain of "DFSMS RMS requires stuff in SFS" by > putting the DFSMS filespace and its SFS Work_directory into > 2 small storage groups > (3 and 4) in VMSYS instead of into VMSYS:'s main, default > storage storage group 2. > > That way I can FILEPOOL UNLOAD and FILEPOOL RELOAD these > DFSMS-RMS storage groups independently of the main storage group 2. > At DR-time I can restore them with FILEPOOL RELOAD before the main > VMSYS: storage group(s) have been restored from backups that > need RMS-mounted tapes. > Minimizes the chicken-egg problem for me. > > > q filepool stor vmsys > > VMSYS File Pool Storage Groups > > > > Start-up Date 08/20/07 Query > Date 03/28/08 > Start-up Time 11:50:57 Query > Time 13:56:14 > ============================================================== > ========== > STORAGE GROUP INFORMATION > > > > Storage 4K Blocks 4K Blocks > > Group No. In-Use Free > > 1 5023 - 56% 3960 > > 2 263300 - 74% 90332 > > 3 10 - 2% 522 > > 4 0 - 0% 2149 > > ============================================================== > ========== > > > -------------------------------------------------------- > This e-mail, including any attachments, may be confidential, > privileged or otherwise legally protected. It is intended > only for the addressee. If you received this e-mail in error > or from someone who was not authorized to send it to you, do > not disseminate, copy or otherwise use this e-mail or its > attachments. Please notify the sender immediately by reply > e-mail and delete the e-mail from your system. > > > -----Original Message----- > > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Kern > Sent: Friday, March 28, 2008 12:47 PM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: DR refresh of active SFS > > On the one system where I do have an ATL and therefore > RMSMASTR, I have also kept real data out of the VMS* > filepools. They are quite small so it is easy and quick to > force RMSMASTR, do the FILEPOOL UNLOAD to CMS disk files and > bring RMSMASTR back up in order to mount the tapes for the > largest SFS and the full volume backups. Or even mount your > backup tape, bring down RMSMASTR, backup the VMS* filepools > to that tape, then bring RMSMASTR back up. > > But the key is that NOTHING else is in the VMS* filepools. > This would be so much easier if RMSMASTR's configuration > files and logs were allowed to be on real CMS minidisks. > > /Tom Kern > /301-903-2211 > > On Fri, 28 Mar 2008 11:31:58 -0500, Marcy Cortes > <[EMAIL PROTECTED]> wrote: > >I opened a SHARE requirement about this. > > > >DFSMS RMS requires stuff in SFS. > >To get a valid backup you must either have some software that > >understands the SFS or have the SFS down. But you can' t > have the SFS > >down or you can't mount a tape if they are in an ATL. > >But you'd like to have RMS available as soon as you restore > your full > >pack so that you can use that special SW you purchased to > restore your > >SFS! > >So, you really have to do a fileserve generate and then copy > in enough > >of your DFSMS configs that hopefully you've kept elsewhere > on minidisk > >in order to get your ATL to work. > > > >In reality, what we do is *hope* that the physcial backup while it is > up > >is ok. We keep nothing but dfsms in there (in the VMS* > filepools) in > >hopes that since it is static, no issues will arise. > > > > > > > >Marcy Cortes > > >
