==> In article <2DC18B3B8E098147A593039AF0019589F1DAA3 AT 
CTG-MSNEXC01.staff.berbee DOT com>, "Stapleton, Mark" <mark.stapleton AT BERBEE 
DOT COM> writes:

> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On
> Behalf Of Tab Trepagnier

>> The problem is that an export is a single transaction.  [...]

> Exports have been notoriously slow to write (and read) from ADSM/TSM
> first iteration. [...]


Oo!

Talk about a lead-in from heaven!

At the SHARE conference last week, I presented a "user experience" session
entitled "50 ways to move your data".  I don't (yet!) actually have 50
technically distinct methods, having eschewed the cheap-shot of classifying
DVD as different from QIC, etc. ;).. but I do discuss a bunch of ways I've
used to transfer data between my TSM servers.

The whitepaper is available on the web at

http://open-systems.ufl.edu/services/NSAM/whitepapers/50ways.html

and I sepcifically invite folks to lay into it.  I would especially welcome
hearing about other "ways" you folks have used.


This particular situation rang bells for me:  So long as you don't have all
your data on just one filespace, you can still accomplish the export/import
in stages, with a lot of micromanagement.

If you export FILESPACE1, you can then add it to the target server's DOMAIN
and remove it from the source server's DOMAIN, like so:

*
* dsm.sys on CLIENTBOX.
*

server SOURCE
[yadda]
domain -FILESPACE1


server TARGET
[yadda]
domaint FILESPACE1


You can, at the cost of spending days (and backup cycles) astride two horses,
accomplish the export with possibly less exposure.


- Allen S. Rout