ADSM-L

Re: Update copygroup question

1998-02-24 16:20:40
Subject: Re: Update copygroup question
From: Trevor Foley <Trevor.Foley AT BANKERSTRUST.COM DOT AU>
Date: Wed, 25 Feb 1998 08:20:40 +1100
Jerry,

I totally agree with you. If, as a user of ADSM, I archived a file to a
specific management class with particular retention attributes, I
wouldn't want that changed without my knowledge. On the other hand, I
have on occasional had the need to change to the retention period for
certain file. Having the retrieve and re-archive is a pain, particularly
for large amount of data. So having the ability to bind those files to a
different management class with different attributes would be very
useful.

I haven't used Q ARCHIVE enough to know that the expiry date of a file
was shown in the V2 client and not in the V3 client. Again I agree with
you. This is something that is needed. We use ABC, the ADSM client for
OpenVMS from SSSI, and it does have this ability and I have used it on
more than one occasion. Is it possible to get this information through
the SELECT interface? Although that isn't the total solution as SELECT
is only available to administrators.


Trevor
        -----Original Message-----
        From:   Jerry Lawson [SMTP:jlawson AT THEHARTFORD DOT COM]
        Sent:   Wednesday, 25 February 1998 7:07
        To:     ADSM-L AT VM.MARIST DOT EDU
        Subject:        Update copygroup question

        ---------------------------- Forwarded with Changes
---------------------------
        From: INTERNET.OWNERAD at SNADGATE
        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 -
        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
<Prev in Thread] Current Thread [Next in Thread>