To avoid the problem of the target for the backup being RELEASEd (due
to restart of the backup SFS), you can use the SFSDOT commands
(explained in sample document on MAINT 193 or 3B2):
CP SEND VMSERVx .CMS ACCESS targpool:space.subdir Z
CP SLEEP 1 SEC
CP SEND VMSERVX BACKUP
This works only after enabling .CMS, as explained in the document:
some .FIND followed by a CP STORE.
Life is easier of you get my SCIF package from the downloadlib, it
will do what is required to enable .CMS.
With human intervention, or from a disconnected server:
EXEC SCIFSFS .CMS ACCESS .....
if connected: press F3 to leave the SCIF session.
To be used in some other exec, working regardless of disconnected state
'PIPE REXX(SCIF EXEC) (SFSCMS) .CMS ACCESS .... |Totarget locate
/Ready/|STEM RESPONSE.'
What is uncertain to me: is the TOTARGET stage: I don't know here at
home what SFS replies after a .CMS ACCESS; without a good TOTARGET (or
a likewise stage) the SCIF EXEC will wait about 15 seconds before
exiting. So run SCIFSFS once and see
2009/6/17 Schuh, Richard <[email protected]>
>
> Mine are 23 3390-03s for one, only 15 in the other. Unfortunately, the user
> community is small but active. There are several CDBs in any given day.
>
> I think what I will do is create a third filepool whose only purpose is to
> host the backups from the other two. That would simplify the coordination of
> the backups. Put each on a 2-hour CDB cycle with one on the even numbered
> hour and the other on the odd. That frequency would probably be often enough
> to keep LUWs from ever being suspended.
>
> Regards,
> Richard Schuh
>
>
>
> > -----Original Message-----
> > From: The IBM z/VM Operating System
> > [mailto:[email protected]] On Behalf Of C. Lawrence Perkins
> > Sent: Tuesday, June 16, 2009 3:28 PM
> > To: [email protected]
> > Subject: Re: Control Data Backups
> >
> > They're both quite large - the data disks are 3 3390-27 but
> > they both enj= oy
> > a "working vacation" in terms of activity. Some huge files
> > get written =
> > to
> > them every morning, then users read them all day long. The
> > user communit= y is also large, but not volatile. The CDB's
> > take place about 3am when no =
> >
> > creatures are stirring, not even mice.
> >
> >
> > On Mon, 15 Jun 2009 16:47:37 -0700, Schuh, Richard
> > <[email protected]> wrot=
> > e:
> >
> > >How large and active (creating, modifying or deleting files,
> > actively =
> >
> > modifying permissions, adding/deleting users, etc.) are your
> > two filepool= s?
> > >
> > >Regards,
> > >Richard Schuh
> > >
> > >
> > >
> > >> -----Original Message-----
> > >> From: The IBM z/VM Operating System
> > >> [mailto:[email protected]] On Behalf Of C. Lawrence Perkins
> > >> Sent: Friday, June 12, 2009 6:39 PM
> > >> To: [email protected]
> > >> Subject: Re: Control Data Backups
> > >>
> > >> On Fri, 12 Jun 2009 14:52:40 -0700, Schuh, Richard
> > <[email protected]>
> > >> wrot=
> > >> e:
> > >>
> > >> >Suppose I have two filepools called SFS1 and SFS2. Would
> > >> having each do
> > >> >=
> > >>
> > >> control data backups to the other cause problems. For purposes of
> > >> this =
> > >>
> > >> discussion, assume that they would not do the backups concurrently
> > >> and th= at neither catalogs nor filespaces share space on the same
> > >> disks.
> > >> >
> > >> >
> > >> >Regards,
> > >> >Richard Schuh
> > >> >
> > >> >
> > >> >
> > >> >
> > >>
> > >> I've been doing just that for 4 years. My "SFS1" and "SFS2"
> > >> are not only=
> > >>
> > >> not on the same disks, they're on two different z/VM systems in an
> > >> ISFC =
> > >>
> > >> collection.
> > >> =========================
> > ==========================
> > =======================
> >
--
Kris Buelens,
IBM Belgium, VM customer support
