WOW ! thanks for pointing that out... I went ahead and tested it on an AIX 4.3.3 TSM 4.2.2.0 server (with AIX tsm client) and sure enough... I archived a few files into a mgmtclass with 365 day retention cut the retention down to 10 days for that management class activated the policy went back to the client & did my "q archive" again and they are ~reported~ to expire in just 10 days now... then because I'm anal (and wanted to see if what was ~reported~ was to be...), I set the host forward one month (more than 10 days but less than 365) accepted the date in tsm & ran expire inventory... sure enough... the data is NO MORE...
OK, now how many sleepless nights will I experience trying to figure out if this is Good or Bad ? Dwight PS below I've included select output from my test... tsm> q archive /home/zdec23/decout* Size Archive Date - Time File - Expires on - Description ---- ------------------- ------------------------------- 96 01/22/2003 13:50:00 /home/zdec23/decout 01/22/2004 365 days 54,673 01/22/2003 13:50:00 /home/zdec23/decout2 01/22/2004 365 days 21,684 01/22/2003 13:50:00 /home/zdec23/decout3 01/22/2004 365 days tsm> tsm: TSMSRV01>upd copy standard standard archtest retver=10 t=a ANR1537I Archive copy group STANDARD updated in policy domain STANDARD, set STANDARD, management class ARCHTEST. tsm: TSMSRV01>q copy standard standard archtest t=a f=d Policy Domain Name: STANDARD Policy Set Name: STANDARD Mgmt Class Name: ARCHTEST Copy Group Name: STANDARD Copy Group Type: Archive Retain Version: 10 Copy Serialization: Shared Dynamic Copy Frequency: CMD Copy Mode: Absolute Copy Destination: DISKPOOL1 Last Update by (administrator): ZDEC23 Last Update Date/Time: 01/22/2003 13:52:35 Managing profile: tsm: TSMSRV01> tsm: TSMSRV01>activate po standard standard Do you wish to proceed? (Yes (Y)/No (N)) y ANR1514I Policy set STANDARD activated in policy domain STANDARD. tsm: TSMSRV01>q copy standard active archtest t=a f=d Policy Domain Name: STANDARD Policy Set Name: ACTIVE Mgmt Class Name: ARCHTEST Copy Group Name: STANDARD Copy Group Type: Archive Retain Version: 10 Copy Serialization: Shared Dynamic Copy Frequency: CMD Copy Mode: Absolute Copy Destination: DISKPOOL1 Last Update by (administrator): ZDEC23 Last Update Date/Time: 01/22/2003 13:52:35 Managing profile: tsm: TSMSRV01> tsm> q archive /home/zdec23/decout* Node Name: DWIGHT Please enter your user id <DWIGHT>: Please enter password for user id "DWIGHT": Session established with server TSMSRV01: AIX-RS/6000 Server Version 4, Release 2, Level 2.0 Server date/time: 01/22/2003 13:54:15 Last access: 01/22/2003 13:51:26 Size Archive Date - Time File - Expires on - Description ---- ------------------- ------------------------------- 96 01/22/2003 13:50:00 /home/zdec23/decout 02/01/2003 365 days 54,673 01/22/2003 13:50:00 /home/zdec23/decout2 02/01/2003 365 days 21,684 01/22/2003 13:50:00 /home/zdec23/decout3 02/01/2003 365 days tsm> tsm: TSMSRV01>show time Current Date and Time on the Server ---------------------------------------- 02/22/2003 14:09:01 UTC (GMT) Date/Time is: 02/22/03 20:09:01 Last Noted Date/Time is: 02/22/03 14:08:57 tsm: TSMSRV01>expire inv ANS8003I Process number 62 started. tsm: TSMSRV01>q pr ANR0944E QUERY PROCESS: No active processes found. ANS8001I Return code 11. tsm: TSMSRV01>q occ dwight ANR2034E QUERY OCCUPANCY: No match found using this criteria. ANS8001I Return code 11. tsm: TSMSRV01>accept date ANR0893I Are you sure that you want to accept the current system date as valid ? Do you wish to proceed? (Yes (Y)/No (N)) y ANR0894I Current system has been accepted as valid. tsm: TSMSRV01> tsm: TSMSRV01>show time Current Date and Time on the Server ---------------------------------------- 01/22/2003 14:09:31 UTC (GMT) Date/Time is: 01/22/03 20:09:31 Last Noted Date/Time is: 01/22/03 14:09:09 tsm: TSMSRV01> Dwight E. Cook Software Application Engineer III Science Applications International Corporation 509 S. Boston Ave. Suite 220 Tulsa, Oklahoma 74103-4606 Office (918) 732-7109 -----Original Message----- From: Miller, Ryan [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 22, 2003 12:59 PM To: [EMAIL PROTECTED] Subject: Re: extending archive retentions Yep, I tested it over a weeks time, archiving data and changing the retention period, it worked as designed. This can actually be found in TSM documentation, the doc is not real clear about doing this, but if you break it down you can see it, the part about the default(If you later change or replace the default management class, the server uses the updated default management class to manage the archive copy)...here is the doc that is from the TSM publications, the Server Guide. Archive Copies Archive copies are never rebound because each archive operation creates a different archive copy. Archive copies remain bound to the management class name specified when the user archived them. If the management class to which an archive copy is bound no longer exists or no longer contains an archive copy group, the server uses the default management class. If you later change or replace the default management class, the server uses the updated default management class to manage the archive copy. If the default management class does not contain an archive copy group, the server uses the archive retention grace period specified for the policy domain. -----Original Message----- From: Cook, Dwight E [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 22, 2003 12:25 PM To: [EMAIL PROTECTED] Subject: Re: extending archive retentions Have you actually tested that ? My understanding (from long ago) was that internally, archives are/were stored with an ~expires on date~ or ~expires after so many days~. A ~security~ feature... once an archive was created, that was it, no changing it... because if you could extend a retention period, you could also shorten it. (but then again, an admin with sys auth would just delete the filespace) I might have to test that... Dwight -----Original Message----- From: Miller, Ryan [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 22, 2003 12:13 PM To: [EMAIL PROTECTED] Subject: Re: extending archive retentions Actually, you can't assign a different management class to an already performed archive, but you CAN alter the management class retention period itself and effectively alter the retention period for all archives that used that management class, so there in lies the possible problem. If other archives have used this management class, they will also be retained for the longer period. But if the number of archives that have used this management class is low, this may be your best and easiest solution. I have done that before to save myself considerable time and effort when things like this need to be done. Once the 5 years is up, change the management class retention time back and all will be normal again. Ryan Miller Principal Financial Group Tivoli Certified Consultant Tivoli Storage Manager v4.1 -----Original Message----- From: Cook, Dwight E [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 22, 2003 11:59 AM To: [EMAIL PROTECTED] Subject: Re: extending archive retentions NO but YES, sort of... NO, you can't alter the management class (and thus the retention period) of archived files BUT you could do something like export the node (or as little data as possible but still including the data you need) then you could save those export tapes for 5 years... When you import a node, you can request that is use "relative" dates, so archived data will still be available for the same number of remaining days as when it was exported. (that was about as clear as mud...) Dwight -----Original Message----- From: Glass, Peter [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 22, 2003 11:19 AM To: [EMAIL PROTECTED] Subject: extending archive retentions I have some clients who have archived files with 1-year retentions. Now they say these files need to be retained for 5 years. Is there a way we can extend these retentions without having to retrieve and re-archive these files? If so, how? Thanks, in advance. Peter Glass Distributed Storage Management (DSM) Wells Fargo Services Company > * [EMAIL PROTECTED] >