Thanks, guys!  I had fallen asleep monitoring this thread and I just now caught 
up on it.  

Yes,  there's a lot of unknowns at this juncture of our re-architecture of the 
TSM environment.  We're introducing TSM DD as much as possible into the 
environment, along with replication between our two datacenters for failover 
(still manual in the TSM server world, but better than before).  Between the 
DD, replication and other advanced functions, I had to rethink all the 
practices that we did back in the TSM v5 days.  Right now, I'm leaning to have 
domains separated by BA and TDP (one per TDP, i.e. oracle, mssql, ve would be 
still OS files) clients.  There would be an OS domain, TDP Oracle, TDP SQL, and 
potentially TDP VE domain.  

The storage pools I'm trying to get to as few as possible to reduce management 
and improve DD ratios (however, this may end up to be a waste of processing 
time).  But at least I'll give it a try.  Administrative timing for all sorts 
of work to happen on one single Dedupe stgpool is a concern.  However, I'm 
relying on my replication server to handle a lot of that work.  The production 
TSM server (the one that all clients will write to) will no longer have to do a 
copy storagepool.  All it will do is a replication job, and then the 
replication server will do all the work for offsiting, including reclamation, 
copy stgpool, etc.  Since all if it will be on disk, daily migration of primary 
pools will be a thing of the past.  I think it's an aggressive architecture, 
and I'm not even sure if it's technically feasible.  But I'll find out here in 
the next month or so.

Sergio