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
>