ADSM-L

Re: [ADSM-L] rebinding objects for API client archives

2017-09-20 09:00:22
Subject: Re: [ADSM-L] rebinding objects for API client archives
From: "Rhodes, Richard L." <rrhodes AT FIRSTENERGYCORP DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 20 Sep 2017 12:58:40 +0000
I think I'm confused (not unusual!).

Rebinding is CHANGING the MgtClass an object is bound to, NOT changing the 
policies within a MgtClass.

If we just change the policies of the MgtClass to retain the archive for 12 
years, that WILL work.  What WON'T work is creating a NEW MgtClass with 12 year 
retention and trying to rebind to that.

The Archive table in db2 has CLASS_NAME, that's what can't change.  But the 
policies in the CLASS_NAME can change.

Of course, changing the policies effect everyone using that MgtClass, but we 
can live with that . . . . I think.


Ok, is that right?


Thanks!

Rick





-----Original Message-----
From: Rhodes, Richard L. 
Sent: Wednesday, September 20, 2017 8:19 AM
To: ADSM-L AT VM.MARIST DOT EDU
Cc: Ake, Elizabeth K. <akee AT firstenergycorp DOT com>
Subject: rebinding objects for API client archives

We have a TSM instance that is dedicated to "applications".  These are 
applications that use the API client to store some kind of object in TSM.  An 
example is IBM Content Manager.  Nodes are in domains with a default Mgt Class 
with 7 years retention, and store their data as Archives, although one 
application uses Backups.  

We received a legal hold request to keep some of this data for 12 years.

It's my understanding that you cannot rebind archive data.  That is, changing 
the MgtClass will do nothing to keep this data longer.  

Do we have to change the Mgt Class and have the users retrieve/re-archive the 
data?


Is this correct?  Thoughts?

Thoughts?

Rick
------------------------------------------------------------------------------

The information contained in this message is intended only for the personal and 
confidential use of the recipient(s) named above. If the reader of this message 
is not the intended recipient or an agent responsible for delivering it to the 
intended recipient, you are hereby notified that you have received this 
document in error and that any review, dissemination, distribution, or copying 
of this message is strictly prohibited. If you have received this communication 
in error, please notify us immediately, and delete the original message.
<Prev in Thread] Current Thread [Next in Thread>

ADSM.ORG Privacy and Data Security by KimLaw, PLLC