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
Bill Colwell
C. S. Draper Lab
Cambridge, Ma.
bcolwell AT draper DOT com
--------------------------
=========================================================================