What Bill did not tell you is that I have a Share requirement in
consideration to assign a management class to an object or objects and lock
it from automatic changes when the next process is run.
Paul D. Seay, Jr.
Technical Specialist
Naptheon Inc.
757-688-8180
-----Original Message-----
From: William F. Colwell [mailto:bcolwell AT DRAPER DOT COM]
Sent: Thursday, August 08, 2002 10:58 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Extend Archive retention period
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.
|
