On Feb 8, 2007, at 4:51 PM, Anker Lerret wrote:

...
The second option is to issue RENAME NODE OLDCLIENT NEWCLIENT and
restore
the stub files on the new client.  Richard Sims outlines the
technique in
http://www.mail-archive.com/adsm-l AT vm.marist DOT edu/msg56480.html .
Here's
my understanding of what Richard proposes:

Step 1: Unmount the HSM filesystem on OLDCLIENT, exposing the stub
files.
Step 2: RENAME NODE OLDCLIENT NEWCLIENT on the TSM server.
Step 3: Use something (scp or tar) to move the stub files to
NEWCLIENT.
Step 4: Mount the HSM filesystem on NEWCLIENT.

...

Hello, Anker -

Where the receiving system has not yet established itself in that
same TSM server, node transfer can be a good method.  The new system
instantly adopts all the filespaces created by the old node,
including the HSM filespaces which are the backstore for all the
stubs.  Naturally, the donor and adopter platforms should be of the
same type, and utilize equivalent or wholly compatible file system
types.

I believe that the best HSM transfer method is to first perform a
recursive dsmmigrate of all its file system data, which leaves only
stubs or small files in the file system.  This is to make the later
restoral faster.  On the new system, you would establish a file
system having the name of the original, then put that under HSM
control.  Now, perform a restoral with RESToremigstate Yes in effect,
to fully populate that newly-established HSM file system with a
directory structure and stub files and files which were too small to
participate in HSM migration.  (Note that the stub files will not
contain any leading file data.)

One last note: We are deeply, almost superstitiously, afraid of
HSM.  We
have had numerous problems with HSM and have never felt comfortable
with
it.  Our only wholesale loss of TSM data involved HSM; our users still
remember it and still have unkind feelings toward TSM because of
it--and
it happened five years ago.  We generally keep all of our software
quite
current, but you will notice that we are running this TSM client at
quite
an old level--because we finally found a level that made HSM behave
well
and we're terrified to change it.  Can anyone say anything that
would make
me feel confident about what we're about to do?

I'm curious about the circumstances of such a data loss, particularly
where there should be backups available.  I've been running HSM for
over a decade without data loss.

I understand your fears: HSM is probably the most complex and Rube
Goldberg-ish facility in TSM, with lots to go wrong.  Delving into
how it works, including inspecting its management files, helps allay
fears and allows you to feel more in control, as well as allowing you
to appreciate what you need to watch out for.

   Richard Sims      (see  http://www.rube-goldberg.com/)