They are, but for retention purposes they do work as the same one.  In
other words, when a node is moved from one domain to another, no rebinding
takes place.  Which I'm very glad of, since I don't know how we'd do this
otherwise.   :-)

_________________________________

Kathleen Hallahan
Freddie Mac





   Larry Clark <lclark01 AT NYCAP.RR DOT COM>
   Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
   10/22/2007 02:01 PM
   Please respond to
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>


To
ADSM-L AT VM.MARIST DOT EDU
cc

Subject
Re: Sropping expiration for specific clients






Ok, just wanted to clarify. Those would be different management classes
even
though they have the same name.

----- Original Message -----
From: "Kathleen M Hallahan" <Kathleen_Hallahan AT FREDDIEMAC DOT COM>
To: <ADSM-L AT VM.MARIST DOT EDU>
Sent: Monday, October 22, 2007 1:33 PM
Subject: Re: [ADSM-L] Sropping expiration for specific clients


> Yes, exactly.  We have a domain with its own copygroup, storage pools,
> etc.  We just reuse the names of the management classes and assign
> different retention to them inside of those.  Since our management
classes
> are pretty standardized anyway, it's not too complicated to do.
>
> _________________________________
>
> Kathleen Hallahan
> Freddie Mac
>
>
>
>
>
>   Larry Clark <lclark01 AT NYCAP.RR DOT COM>
>   Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
>   10/22/2007 01:29 PM
>   Please respond to
> "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
>
>
> To
> ADSM-L AT VM.MARIST DOT EDU
> cc
>
> Subject
> Re: Sropping expiration for specific clients
>
>
>
>
>
>
> hmmmm.......
> so would you define a new copygroup in the new domain with new retention
> rules using the same managment class (name)?
>
> ----- Original Message -----
> From: "Kathleen M Hallahan" <Kathleen_Hallahan AT FREDDIEMAC DOT COM>
> To: <ADSM-L AT VM.MARIST DOT EDU>
> Sent: Monday, October 22, 2007 1:15 PM
> Subject: Re: [ADSM-L] Sropping expiration for specific clients
>
>
>> Joy,
>>
>> Our approach has been to create a separate domain which contain the
same
>> management classes that the data is already bound to.  In this way, we
> can
>> move the affected nodes to the new domain with no rebinding of data,
and
>> maintain the inactive as well as the active data.  It also allows TSM
to
>> continue tracking and protecting the data  We then, of course, expect
> the
>> platform areas to restore the data they need to a separate location, so
>> that we aren't stuck with open-ended interminable retention
requirements
>> that no one can agree to revert....
>>
>> Hope this is useful!
>>
>> Kathleen
>>
>> _________________________________
>>
>> Kathleen Hallahan
>> Freddie Mac
>>
>>
>>
>>
>>
>>   Joy Hanna <JoyHanna AT FREIGHTLINER DOT COM>
>>   Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
>>   10/22/2007 12:59 PM
>>   Please respond to
>> "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
>>
>>
>> To
>> ADSM-L AT VM.MARIST DOT EDU
>> cc
>>
>> Subject
>> Sropping expiration for specific clients
>>
>>
>>
>>
>>
>>
>> Hello,
>>  Due to a legal request we are being asked not to expire any data for
>> some specific TSM clients. Is there a way to exclude a group of clients
>> from expiring any data for a time period? I see there is a way to do
>> this for archived data. I'm talking incremental backup data. If I stop
>> expiring altogether I think it wouldn't be long before I put my whole
>> environment at risk. The only way I can think of to do this would be to
>> rename all filespaces where I suspect there might be data I do not want
>> to expire. This however would cause all those renamed filespaces to
back
>> up in full tonight. We're talking several TB of file server data. Any
>> ideas? Sincerely, Joy
>>
>> Joy Hanna
>> Enterprise Storage Group
>> I.T. Computer Operations
>> (503)745-7748
>> Joyhanna AT freightliner DOT com
>>