OpenVMS merge of SYSUAF files

[HarrinG]

I am setting up a new server to replace an existing server for a client. I have read in the FAQ for OpenVMS that I can use the "Convert/merge" process described in the OpenVMS clustering to merge the SYSUAF file from the old server into the SYSUAF file on the new server.

After a backup of my SYSUAF file I attempted the process, but I received a bunch of errors and the SYSUAF file output was corrupted. I restored my backup of SYSUAF, but I am wondering what could have gone wrong.

I am running an Alphaserver ES45 OVMS 7.3-2 with V011 patches on the new server and an Alphaserver DS12 OVMS 7.3-2 with V009 patches for the old server.

The servers are in seperate states so I attempted to FTP (set binary) the SYSUAF from the old server to the new server before trying the "Convert/merge".

Has anyone attempted to do something like this or can anyone let me know what I might be doing wrong?

[Hoff]

If you have a corrupt SYSUAF, there's a problem that needs to be addressed before the merge. Start by figuring out where the corruption error has crept in.

FTP is one potential culprit. FTP can very easily corrupt OpenVMS file attributes, and particularly if the file visits other platforms on the way between systems.

If you have other systems involved, did you zip "-V" the file beforehand? zip "-V" will protect the file.

Details on merging or removing nodes from a cluster are in the appendix of the cluster manual, and you can also find some details here:
http://64.223.189.234/node/169

Errors made in this area can potentially render the systems unstable, or can create some subtle and latent errors. There's rather more than SYSUAF involved here -- merging SYSUAF and resolving the duplicates is arguably the easy part. Those pesky identifiers can get ugly. See the cited /node/169 for additional details on what's involved.

I probably wouldn't bother with the merge approach here, if this is a new server replacing an old server. I'd probably replicate the system disk over (live or otherwise, for the purposes of testing the baseline it's not as critical to get solid data), test the new box and the existing applications off to the side (and track the changes needed), and then shut down and re-replicate the system and disks over, and apply the changes. The changes here are usually constructs such as the physical device names, should these have changed.

Stephen Hoffman
HoffmanLabs

[Robert Gezelter]

HarrinG,

I have done this many times. It is not quite simply a matter of doing a merge on the two files. More care is needed.

For starters, it is necessary to verify that the UICs for the various products are the same on both systems. If that is the case, you can simply replace the new system's UAF with the UAF from the old server.

You will of course, need to do some mass changes if you have named disks differently in the two configurations (I always use concealed logicals to hid the details from user accounts, but the post did not include details about the old system).

For transfer, since the UAF (and RIGHTSLIST) are keyed files, I generally use BACKUP, then ZIP/UNZIP before FTPing the files, for safety. Using this method, I have never had a problem with either file attributes or corruption.

If I have been unclear, or can be of assistance, please let me know.

- Bob Gezelter, http://www.rlgsc.com

[Anton van Ruitenbeek]

HarringG,

Its not always better to keep old information. Sometimes its better to extract these files and create a new one. This cleans also old unneeded and other stuff you never knew they were there.
Last time I did a merger of big authorisationfiles and did this by extracting, modifying (using ofcourse command procedures) and import to a new file.

Please don't forget that queuefiles and onther processes use the authorizefile which was present when started these processes. If you create a new SYSUAF and RIGHTSLIST you must make sure the needed processes restart/use these new files !

AvR

[HarrinG]

I actually did what the last poster sugggested and extracted the users using the LIST utility then create a DCL procedure to populate the new SYSUAF. This worked well.