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
> --------------------------
>
|