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
>
