ADSM-L

Re: Archive vs. Backup (snapshot enhancement)

1999-02-03 12:29:20
Subject: Re: Archive vs. Backup (snapshot enhancement)
From: Joel Fuhrman <joelf AT CAC.WASHINGTON DOT EDU>
Date: Wed, 3 Feb 1999 09:29:20 -0800
The version 3.1.2.13, which is available via the ftp site in the fixtest
directory, contains a fix for the "The 3.1.2.1 servers don't expired version
beyond the verexists limit" problem.

On Wed, 3 Feb 1999, Bill Colwell wrote:

> Paul,
>
> I agree completely about looking for the best design points.  When I write
> up a requirement to submit thru SHARE,  I try not to ask for something that
> would more or less want a silk purse from a sow's ear (no reflection
> intended on the current state of ADSM).
>
> As to having extra inactives beyond the verexists parameter, IBM is running
> that experiment right now!  The 3.1.2.1 servers don't expired versions
> beyond the verexists limit.  Of course, they call it a bug today, but maybe
> someday it will be a feature!
>
> Bill
>
> In <3.0.2.32.19990202174018.00f8c800 AT postoffice3.mail.cornell DOT edu>, on
> 02/02/99
>    at 05:40 PM, Paul Zarnowski <vkm AT CORNELLC.CIT.CORNELL DOT EDU> said:
>
> >At 11:45 AM 2/2/99 -0500, Bill Colwell wrote:
> >>The key issue
> >>for implementing this is to flag all the file versions that make up the
> >>active set so that when some of them are no longer part of the active set
> >>and subject to expiration, expiration is inhibited.
>
> >Yes, I agree.  I'm just not sure what the best way of implementing this is.
> > I think it's important to not corrupt the existing definition of
> >management classes.  If a backup management class indicates that 3 inactive
> >versions of a file should be kept, that's pretty explicit and easy to
> >understand.  If you introduce potential exceptions to this rule, that could
> >complicate things (for both users and ADSM developers).
>
> >I'm looking for some design point that would minimize disruption of
> >existing concept definitions.
>
> >..Paul
>
> --
> --------------------------
> Bill Colwell
> C. S. Draper Lab
> Cambridge, Ma.
> bcolwell AT draper DOT com
> --------------------------
>