Hi Terry,

You are not missing much, if anything.
There had been an old requirement for adsm 
to support moved directory trees within or among file servers,
but currently has *sm server still a quite static view of
client´s ressources, at least on Wintel Plattforms.

What is your exact concern?

Do you want to prohibit first very-large incremental backup
because of ressource shortage on your *tsm server?
No straight way to achieve this. You can play
with include/exlude so that not everything will be backed-up
the first day. Or start manuall backups for
certain subdirectories only.
But avoid this option if you can, because
it leaved eventually your G: not 
fully backuped in the begining of its existence.


Do you want to get rid of old F: backups as soon as possible?
If whole of F: is to be deleted, so simply perform 
DELETE FILESPACE at an appropriate later time.
If only a subtree is to be deleted,
define management-class TRASHCAN with small
values of your choise for 
VersionsDataExist;VersionsDataDeleted;
RetainExtraVersions;RetainOnlyVersions;
bind it to subtree concerned in you OPT file:
        include F:\YourSubtree\...\*    TRASHCAN
and run an incremental backup of f:\subtree
both prior and after having it deleted from file server.
The first backup will rebind your files, the second
wil kick-on the VersionsDataDeleted and RetainOnlyVersions
expiration parameters.

This answers your question as well: "If I bind the 
new management class to one, won't it actually
bind it to both?"
As you see, due to syntax of management class binding
the mgmt class will only be bound to directories/files 
explicitly specified. ADSM has really NO knowledge
about relationship between F:\YourSubdir
and G:\YourSubdir. It only sees files emerging 
and dissapearing.
The G: will be bound to your DEFAULT mgmt class,
except that you bind it explicitly in the OPT file:
        include F:\YourSubtree\...\*    AnotherMGMTClass        
        


Doing all of above,You should check your customer
policies, because there might be a D A N G E R
that you let backups versions expire, which
your customer will need have restored later.
For example, let us suppose you guarantee
your customers to keep 3 versions
of a file for a month. Now when you have
moved F: to G:, performed backup
from G: and have F:\YourSubtree expired,
you cannot restore any second or third version of
a file...
In such case, your  TRASHCAN must be set as follows:
both VersionsDataDeleted and VersionsDataExist
must not be smaller than VersionsDataExist 
from the original (default?) management class.
RetainExtraVersions must not be shorter than its old counterpart.
RetainOnlyVersions must not be shorter than any of above.
? maybe I forgot something?


Extra points not to forget:
Do not forget to check your DOMAIN statement after
moving data from F: to G: (it has to be
either "all-local" or have "G:" included).
Do not forget to (re)start *tsm client scheduler 
after any changes to its OPT file.


hope it helped - but you were on the right way anyway

Juraj Salak
KEBA AG
Linz, Austria
sal AT keba.co DOT at