Change mgmtclass for archive

[Venzent]

I have an archive of some filesystems on AIX. 1 archive of March this year is bound to the default mgmtclass wich expires in 1 year (March 2010). I now got the request to safe it for 10 years. I cannot restore and archive it again, can I somehow expend the period or change the mgmtclass of an archive?

 

[Samuel]

When you archive a file for the first time, TSM binds it to the default management class, to the management class specified in your include-exclude list, or to a management class you specify when modifying your archive options during an archive.

Archived files are never rebound to a different management class. If you change the management class for a file, any previous copies of the file that you archived remain bound to the management class specified when you archived them

 

[Samuel]

extract of :
http://www.unix.ualberta.ca/TSM/tsmunix/ans50011.htm
Binding and Rebinding Management Classes to Files

 

[Venzent]

I know this, my question is, how can I retain the files longer then intended in the first place?

 

[Samuel]

more possibility :
you upgrade the value of default retention for archive or you create a new archive copy group with a new value.
When you archive you specify this managmentclass for example you create on domain AIx a archive copygroup arch_10Y (with 3650 days of retention). after
dsmc archive /tot/* -subdir=yes -archmc=arch_10Y ......

For me i hva 5-6 archive copy group with different values, when i archive i specify the managment class archive. Sorry for my explain, i'm french and i don't found the correct word for traduce in english

 

[Venzent]

Changing the default is not an option, creating a new mgmt doesn't change the experations for the excisting archive.

 

[Samuel]

Create a new mgmt class doesn't change your current archive.
The solution is restore your archive on new partition or server, re-archive with the correct value.

 

[BBB]

Create a new policy domain with the required management classes, with the new retentions you require, then move the node to the new policy domain.

Messy but the only way to do it.