In experimenting with export-import, one problem I find is the apparent
inability to reattribute the filespace to the node native to the ADSM server,
particularly with HSM file systems.  For example: filespace "F" (and its file
system) has been owned by node N1, with the ADSM server running on that node,
and you want to move the file system to ADSM server node N2 such that the file
system is to be resident there (for best HSM operation).
    The problem is that after importation the filespace still shows up as
belonging to N1, and there is no way to reassign it to N2.  This is a
particular need with HSM file system migration in that almost all the data
exists within the filespace rather than the file system, and one would
certainly like to simply transfer the filespace to the new server by means of
doing a RESToremigstate=Yes type of restoral such that the stubs and small
files are recreated in the same-name file system in the new ADSM server,
pointing to the data store which exists in the filespace.
    Because it is apparently impossible to tell ADSM to give the imported data
to a specified node, one instead has to perform a full, cross-node restoral
with RESToremigstate=No to populate the receiving node (N2) filespace with the
data, which is a prolonged travail for HSM, punctuated with situation
messages:
 ANS4103E Ran out of disk space trying to Restore <File_Name>.
          Retry/skip/abort (r/s/a)? _
requiring continual manual response after HSM migration has reduced the
utilization level (this at the latest v.2 server and client levels).
    I've been through the manuals, including the HSM redbook, but
find nothing advising on meeting this need.  If anyone has found
a good way to deal with it, I'd appreciate suggestions.
        thanks, Richard Sims, BU