We just went through a disaster recovery test, using the following process
for each Windows 2000 system involved:

1.Give the replacement system a different computer name than its production
counterpart.
2.Execute a 'rename node' command against the recreated TSM database to
change the node name matching the production computer name to a node name
matching the replacement system computer name.
3.Execute 'rename filespace' commands to make the corresponding changes to
computer names embedded in UNC volume names.
4.Restore the C drive.
5.Restore the system object.
6.Restore the remaining drives.

At step 5 the attempt to restore the system object finished almost
instantly, with no data movement. This was true whether the GUI or the
command line client was used. The 'query systemobject' claimed that there
were no matching files. I called IBM and was told that a system object
cannot be restored to a system with a different computer name than the
system that backed up the system object. We were using 5.2.6.0 server code
under mainframe Linux. We were, in most cases, installing 5.3.2.0 client
code on the replacement Windows systems (one Windows administrator tried
the 5.1.5.0 client code and got the same results). Some of the original
production systems had been running 5.3.2.0 client code, and some had been
using lower client levels.

Several of the Windows administrators confirmed my recollection that the
process described above had been used successfully at our previous disaster
recovery test 14 months earlier. We are then using 5.2.2.0 server code and
a variety of 5.1 and 5.2 client code levels.

This raises a number of questions:

1.Why did our test recovery process stop working?
2.Is there any way to get the process to start working again?
3.Nearly every book or article about disaster recovery emphasizes the
  importance of testing. Why did Tivoli introduce a restriction that
  seems to have been designed to make disaster recovery testing
nearly impossible?