Mike D'Amico,
Almost certainly you do not want to recreate the "cluster personality files" from scratch. I.e. you should just copy the SYSUAF.DAT, RIGHTSLIST.DAT etc. instead of recreating them. If you are migrating user disks as well, the protection of the files is based on the UIC/identifiers, and if you recreated the above files, it is very likely that the values of some of the UICs or identifiers will change, and then the correct users won├в t own the files. For the queues, my experience is that a backup /ignore=interlock of an idle system will backup the queue database is a way that the queues/forms/characteristics will be restored, but no entries will be brought along. In most cases, that is a good thing, since if you restore a system disk a month after the backup was done, it is very likely that many timed release jobs will have passed their /after time and will start executing as soon as the queues are started. A good thing to have handy is a command procedure that can recreate your queues, forms and characteristics from scratch. If you use Google, you should be able to find command procedures that will create such command procedures based on your current queue database files.
For a list of these files see Hoff's introductory information on adding nodes to a cluster, and a cluster divorce:
http://64.223.189.234/node/169 I would use the backup utility to copy the files, as it had the ability to preserve more about the files than copy does:
$ backup src:[000000]toplevel.dir dst:[000000]toplevel.dir/own=original
$ backup src:[toplevel...]*.*;* dst:[*...]*.*;*/own=orig/truncate
Will duplicate the [toplevel] directory and all its subdirectories and files with the original file security information (ownership/protection/ACLs), and will use the minimum amount of disk space needed on the destination disk (/truncate). This is especially important if the clustersize on the destination disk is different from (and relatively prime to) the clustersize of the source disk.
restored.
Other issues you many need to consider. If you have layered products, you will need to resister/load the license PAKs. If your software allows a transfer, then the units issue shouldn't be a factor, as the units for an 8400 will be larger than an ES40.
If your startup command procedures have hardcoded device names, it is time to change them to use logical names. That can be done before the move, so you don't have nasty surprises the day you move.
If your node name is changing, you may need to modify the licenses to reserve them to a different node. BTW, this is one area that license/issue/procedure does not do everything needed to be able to recreate the license database from the command file it creates.
You will definitely want to do a dry run on the new system before the move, i.e. take boot the new system from a CD, and get a complete backup of the drive as it was delivered to you, or if you have disk space, a second bootable disk copy. This is your "baseline". Now do your restore from tapes, etc and keep a good record of what you do. When you are done, your new system should be a logical clone of the original, and should behave identically (given limitations of the hardware configuration). Have people test what can be tested. You will probably find some things that break because of assumptions made by command procedures (the killer is disk references like
$ open/read/error=custdata_openerr infile $6$DKA200:[DATA]CUSTOMER.DAT
and the data that was on $6$DKA200 is now on $1$DGA302. Much better to use something like
$ open/read/error=custdata_openerr infile DISK$DATA:[DATA]CUSTOMER.DAT
it depends
