See responses below:

Can anyone comment on modifying this procedure by following these steps:
1.    Create a domain called "Freezer" with only one mgmtclass - bu/ar
copygroup settings all at nolimit
2.    upd node water domain=freezer
3.    run an incremental on water to rebind all data to freezer's
mgmtclass
4.    rename node water ice
5.    register water, using original settings
6.    run an incremental backup on water, basically a full since it is
considered a "new" node

If I understand TSM's mechanisms, I would then have a node named "ice"
that
contains all of "water's" backup data as of a specific point in time,
which
will never expire.  I also have "water" with a fresh start.  One
question I
have is that with only one mgmtclass in the freezer domain, how much
will
TSM complain if I don't go in and change all of the client option sets
pointing to specific mgmtclasses? 

>>The simple thing to do:  create the FREEZER domain by making a COPY of
the original domain.
That way all the mgmtclasses will line up properly, you won't get a lot
of TSM whining when expiration runs.
You will have to change ALL the copygroups in the domain to NOLIMIT, but
that's not hard.
Using a copy of the domain is cleaner.
 

Another question - how does this process
affect water's data in the DR copypools?

>>Um.  "water" was renamed to "Ice".
SO "water" now has NO data in the DR copy pools, until you run a BACKUP
STGPOOL.  Then you get a copy of "water"s fresh data in the copy pool
under the name "water".

ALL the old data turned to "Ice" (hee hee) when you did the rename,
files in the copy pool included.
And since you changed the the bu/ar copygroup settings to nolimit, the
copy pool data will never expire either.

Think of the file entries in the TSM DB this way:

 <file version name /pointer to primary pool tape /pointer to copy pool
tape /pointer to copy pool2 tape (if exists)/ etc.> 

Every file that is backed up in the primary pool, has a pointer to its
copy in copypool1, a pointer to its copy in copypool2 (if it exists),
all in the same DB record.
If you delete the record for the file in the primary pool, you delete
the copy in the copy pool.

You can't delete the copy pool copy, without also deleting the primary
copy (except by doing a delete volume discarddata=yes on the copy pool
tape volume)  The prmary and copy pool image of the file are permanently
linked together.

Wanda Prather
"I/O, I/O, It's all about I/O"  -(me)