I can see both sides of this discussion, which is one of the things that
leaves me uneasy.
It also brings up a concern that I had a long time ago (under V1) and still
hasn't been addressed - logging of critical events. There are two related
issues here. First - in this example - if I change a policy domain, it would
be nice to see an indication that it happened in the log, and also perhaps
something about the severity (How many files were impacted by the change?)
Secondly, and perhaps more important, why can't we see the name of the
administrator who issued a command on the line. For example, if a filespace
backup is deleted, add the administrator who issued the command to the
message. In our shop, we have administrators in customer areas with Policy
access to manage their own customers. I would like to know what they are
doing in case of problems.
The combination of these two would probably do a lot to make me feel better
about this process. I think I submitted a requirement on this, but it was
years ago.....
Jerry Lawson
jlawson AT thehartford DOT com
______________________________ Forward Header __________________________________
Subject: Re: Update copygroup question
Author: INTERNET.OWNERAD at SNADGATE
Date: 2/24/98 4:24 PM
Hello Jerry,
for me, I definitely prefer the way it is, I mean the rebinding of
files. In this way, it is possible to change retention later on, if the
data's owner change his mind.
Thanks,
Rene Lambelet, Nestle, VEVEY
>-----Original Message-----
>From: Jerry Lawson [SMTP:jlawson AT THEHARTFORD DOT COM]
>Sent: Tuesday, February 24, 1998 9:07 PM
>To: ADSM-L AT VM.MARIST DOT EDU
>Subject: Update copygroup question
>
>---------------------------- Forwarded with Changes
>---------------------------
>From: INTERNET.OWNERAD at SNADGATE
>Date: 2/24/98 9:00AM
>To: Jerry Lawson at ASUPO
>*To: *ADSM-L at SNADGATE
>Subject: Update copygroup question
>-----------------------------------------------------------------------------
>--
>Reinhard -
>
>You are correct and I was wrong :-(
>
>I did some research and tests here, and found some things I am not quite
>comfortable with. I set up an Archive copygroup with 10 days retention,
>archived a file, then changed the copygroup to 30 days, and then activated
>the changes. Sure enough, the file now had a 30 day retention. I checked my
>V2 manuals, and the Update Copygroup command says that the changes are
>applied to all files bound to this class. This is consistent with what I
>found, and what you pointed out.
>
>I am not quite sure this is what a user expects - I personally expect that if
>I archived something with a set retention, then it would be there for that
>period of time, unless it was specifically deleted. As this stands, if I
>have a long retention file, and someone changes the Archive copygroup
>associated with this file to a short one, my file may already be past
>expiration - I would therefore assume that it would be deleted when the new
>copygroup is activated. (I couldn't test this on short notice). Does anyone
>agree here, or do you think the rebinding of the files is OK (especially
>since it is consistent with the "binding of files" to a MC.)
>
>The other issue here was the new V3 Win32 client - when I went to test the
>scenario, I found that the new client does not give you any way of finding
>out what is ready to expire - there is no longer a Query by expiration date
>as there was with the V2 client (I actually tested on a V2 Windows 3.1
>client.) It would seem to me to be a valued part of the V2 client that has
>been lost - I know I have on more than one occasion done a search for files
>that were about to be expired from the Archive, then retrieved the files I
>wanted and re-archived them to extend their "life". Reinhard, you pointed
>out a way to do this, but it is cumbersome at best and requires that the
>customer be aware of the date a file was archived and what the period of
>archive is currently. If he or she is unaware of this, they might be missing
>something. I would think that the old format of query by expiration date
>range is something that is needed. Again - does anyone agree?
>
>Jerry Lawson
>jlawson AT thehartford DOT com
>
>
>______________________________ Forward Header
>__________________________________
>Subject: Update copygroup question
>Author: INTERNET.OWNERAD at SNADGATE
>Date: 2/24/98 9:00 AM
>
>
>Jerry,
>
>I think, the change also applies to the files already archived.
>
>Actually, I just took a look at the SQL table layout in V3: the expiration
>date is not stored in the ARCHIVES table; it hence has to be calculated
>from the ARCHIVE_DATE field and the mgmt class.
>
>Jerry Lawson writes:
> > Lio -
> >
> > New files of course will be archived for 120 days. Old files previously
> > archived for 90 days will stay at 90 days. If you need to extend them,
>they
> > would have to be retrieved, and then rearchived.
> >
> > Jerry Lawson
> > jlawson AT thehartford DOT com
> >
> >
> > ______________________________ Forward Header
>__________________________________
> > Subject: Update copygroup question
> > Author: INTERNET.OWNERAD at SNADGATE
> > Date: 2/20/98 12:32 PM
> >
> >
> > If I have an archive copygroup defined with retver set to 90 days, what
> > happens if I change retver to 120 days ? Presumably new files archived
> > will be kept for 120 days, but what of files already archived ? Do they
> > keep the old retention period or get the new one ?
> >
> > --
> > best regards
> >
> > Lio Frost-Ainley
>--
>Reinhard Mersch Westfaelische Wilhelms-Universitaet
>Universitaetsrechenzentrum, Einsteinstrasse 60, 48149 Muenster, Germany
>E-Mail: mersch AT uni-muenster DOT de Phone: +49(251)83-31583
|
