Kathy, you can trust the calculation TSM makes because it does
the same calculation during expiration processing. When archives
are made, TSM does not store an expiration date in the archive
entries in the database precisely for the reason that an admin may
change her mind about how long to keep archives, as you have done.
(The same applies to backups too).
What is sorely missed from TSM is a tool to target individual
archives or backups to change the management class the file is
bound to.
Hope this helps,
Bill
At 08:26 AM 8/8/2002, you wrote:
>Dear all,
>
>Thank you for all your advice here. But I still feel confusing about whether
>I can extend the retention period for an already archived file. I try
>perform the action suggested by Reinhard (i.e. change the retver of the
>copyg for the management class that I use to archive those files and then
>use query archive command to check the expired date of that files), it does
>seems works as the expired date change to a new value. But it is really
>reflect the actual expire date of that archived file? Will it just show me
>the calculation result and expire the archived file on the original expired
>date?
>
>Thank you very much.
>
>> Regards,
>> Kathy Lai
>> Outsourcing & Managed Services
>> Pacific Century CyberWorks
>> * 852-8101 2790
>> kathy.kl.lai AT pccw DOT com
>
>
>-----Original Message-----
>From: Reinhard Mersch [mailto:mersch AT UNI-MUENSTER DOT DE]
>Sent: Thursday, August 08, 2002 6:03 PM
>To: ADSM-L AT VM.MARIST DOT EDU
>Subject: Re: Extend Archive retention period
>
>
>Hi Eric,
>
>"Loon, E.J. van - SPLXM" <Eric-van.Loon AT KLM DOT COM> schrieb:
>> Hi Reinhard!
>> I stand correct... There is no rebinding when you update a
>> managementclass/copygroup.
>
>.. and you stand incorrect when saying "So updating an archive copygroup
>will NOT work for already existing archives." And THIS was the original
>question.
>
>Best regards,
>
>Reinhard
>
>> Kindest regards,
>> Eric van Loon
>> KLM Royal Dutch Airlines
>
>> -----Original Message-----
>> From: Reinhard Mersch [mailto:mersch AT UNI-MUENSTER DOT DE]
>> Sent: Thursday, August 08, 2002 08:55
>> To: ADSM-L AT VM.MARIST DOT EDU
>> Subject: Re: Extend Archive retention period
>
>
>> Hi Eric,
>
>> what do you mean by "rebound"? Backups may be "rebound" to a different
>> mgmclass, e.g. by specifying a new one in the inclexcl list. You are
>right:
>> This does not happen for archives, but nevertheless: If the mgmclass an
>> existing archive is bound to is changed, this change also applies to that
>> existing archive.
>
>> Let's do the test I spoke of (4.2.2.0 server on AIX 4.3.3, 4.2.2.0 client
>> on Linux, copy group "test" retains for 30 days):
>
>> client> dsmc ar -archmc=test archive-test
>> client> dsmc q ar archive-test
>> ...
>> Size Archive Date - Time File - Expires on - Description
>> ---- ------------------- -------------------------------
>> 733 08.08.2002 08:35:28 /home/mersch/tmp/archive-test
>> 07.09.2002 Archive Date: 08.08.2002
>> ...
>
>> server> upd co ba std test t=a retv=400
>> server> activate pol ba std
>
>> client> dsmc q ar archive-test
>> ...
>> Size Archive Date - Time File - Expires on - Description
>> ---- ------------------- -------------------------------
>> 733 08.08.2002 08:35:28 /home/mersch/tmp/archive-test
>> 12.09.2003 Archive Date: 08.08.2002
>
>
>> See the change in the "Expires on" field? 07.09.2002 (07-Sep-2002) to
>> 12.09.2003 (12-Sep-2003)!
>
>> So, now you ...
>
>> "Loon, E.J. van - SPLXM" <Eric-van.Loon AT KLM DOT COM> schrieb:
>> > Hi Reinhard!
>> > As a matter of fact: NO!
>> > Backups are rebound to the new backup copygroup/managementclass (and
>thus
>> > retention) archives will NOT be rebound. So updating an archive
>copygroup
>> > will NOT work for already existing archives.
>> > Kindest regards,
>> > Eric van Loon
>> > KLM Royal Dutch Airlines
>
>
>> > -----Original Message-----
>> > From: Reinhard Mersch [mailto:mersch AT UNI-MUENSTER DOT DE]
>> > Sent: Wednesday, August 07, 2002 09:12
>> > To: ADSM-L AT VM.MARIST DOT EDU
>> > Subject: Re: Extend Archive retention period
>
>
>> > For a definite answer, you will need a developer, but to the best of
>> > my knowledge, an object's DB entry does not contain the object's
>> > expiration date. It contains the management class ID it is associated
>to,
>> > and during inventory expiration the decision is based on the archive
>> file's
>> > creation date and the current management class settings. So, yes:
>changing
>> > the management class / copy group parameters applies to all existing
>> archive
>> > files belonging to that management class (same for backups). This
>applies
>> > to all *SM versions.
>
>> > You can easily test it: the command line client shows the expiration
>date
>> > of archive files. So issue a "query archive", change the management
>class,
>> > and issue a "query archive" again. The expiration date should have
>> > changed.
>
>> > Don't forget to activate the policy set.
>
>> > "Lai, Kathy KL" <Kathy.KL.Lai AT PCCW DOT COM> schrieb:
>> > > Dear all,
>
>> > > I am using ADSM v3.1.2.57 for backup. I am now have a questiong about
>> > > whether I can extend the retention period of an archived file. I have
>> > create
>> > > a archive type copy group and a management class with certain
>retention
>> > > period which is not the default management class (say 7days). Then I
>use
>> > > this management class and copy group to archive a file. My question is
>> > > whether I can change the retention of that file already archived by
>> > changing
>> > > the retention period of the management class? By change the retention
>> > period
>> > > of the management class, will it effective to both file already
>archived
>> > and
>> > > new archive file after the change or just effective to file archive
>> after
>> > > the change? If I can change the retention period of an archived file
>by
>> > > change the retver of the management class, does it mean that I have to
>> > > retrieve the file and then re-archive it for a longer retention?
>
>> > > Please urgently reply me the question as I am using this method to
>> backup
>> > > the DB archive. User now request to hold a certain online backup image
>> of
>> > a
>> > > DB. Now I can only hold the expiration job for the backup image only
>but
>> > not
>> > > the DB archive. Thank you very much.
>
>
>> > > > Regards,
>> > > > Kathy Lai
>> > > >
>
>> > --
>> > Reinhard Mersch Westfaelische
>Wilhelms-Universitaet
>> > Zentrum fuer Informationsverarbeitung - ehemals
>Universitaetsrechenzentrum
>> > Roentgenstrasse 9-13, D-48149 Muenster, Germany Tel:
>+49(251)83-31583
>> > E-Mail: mersch AT uni-muenster DOT de Fax:
>+49(251)83-31653
>
>
>> > **********************************************************************
>> > For information, services and offers, please visit our web site:
>> > http://www.klm.com. This e-mail and any attachment may contain
>> confidential
>> > and privileged material intended for the addressee only. If you are not
>> the
>> > addressee, you are notified that no part of the e-mail or any attachment
>> may
>> > be disclosed, copied or distributed, and that any other action related
>to
>> > this e-mail or attachment is strictly prohibited, and may be unlawful.
>If
>> > you have received this e-mail by error, please notify the sender
>> immediately
>> > by return e-mail, and delete this message. Koninklijke Luchtvaart
>> > Maatschappij NV (KLM), its subsidiaries and/or its employees shall not
>be
>> > liable for the incorrect or incomplete transmission of this e-mail or
>any
>> > attachments, nor responsible for any delay in receipt.
>> > **********************************************************************
>
>> --
>> Reinhard Mersch Westfaelische Wilhelms-Universitaet
>> Zentrum fuer Informationsverarbeitung - ehemals Universitaetsrechenzentrum
>> Roentgenstrasse 9-13, D-48149 Muenster, Germany Tel: +49(251)83-31583
>> E-Mail: mersch AT uni-muenster DOT de Fax:
>> +49(251)83-31653
>
>
>> **********************************************************************
>> For information, services and offers, please visit our web site:
>> http://www.klm.com. This e-mail and any attachment may contain
>confidential
>> and privileged material intended for the addressee only. If you are not
>the
>> addressee, you are notified that no part of the e-mail or any attachment
>may
>> be disclosed, copied or distributed, and that any other action related to
>> this e-mail or attachment is strictly prohibited, and may be unlawful. If
>> you have received this e-mail by error, please notify the sender
>immediately
>> by return e-mail, and delete this message. Koninklijke Luchtvaart
>> Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be
>> liable for the incorrect or incomplete transmission of this e-mail or any
>> attachments, nor responsible for any delay in receipt.
>> **********************************************************************
>
>--
>Reinhard Mersch Westfaelische Wilhelms-Universitaet
>Zentrum fuer Informationsverarbeitung - ehemals Universitaetsrechenzentrum
>Roentgenstrasse 9-13, D-48149 Muenster, Germany Tel: +49(251)83-31583
>E-Mail: mersch AT uni-muenster DOT de Fax:
>+49(251)83-31653
----------
Bill Colwell
C. S. Draper Lab
Cambridge Ma.
|
