On Feb 12, 2007, at 9:22 PM, Anker Lerret wrote:

Since I posted yesterday, I've learned that the new copy of the HSM
filesystem will not be placed on a new TSM client, but on a client
that's
already defined to the TSM server.  That means that the RENAME NODE
technique won't work.  In fact, I can't see a way to tell TSM that a
filespace is moving to another TSM client.  It doesn't matter, though,
with the RESTOREMIGSTATE technique.

Anker -

The restoral of stubs is viable only when there is an HSM filespace
on the TSM server to which they point.  Whereas you cannot use the
technique of reassigning node data, you will not have such a backing
store, so the "RESToremigstate Yes" approach cannot work.  You will
likely have to resort to "RESToremigstate No" to fully restore the
foreign file system contents to the new server, and let that migrate
to the HSM backstore of the new HSM client.  This can obviously be
painful, and is best performed in stages, as in a directory at a
time, to give migration the opportunity to operate.

   Richard Sims   http://people.bu.edu/rbs/