Operating System - OpenVMS
Showing results for 
Search instead for 
Did you mean: 

User(s) transfer from 7.2 to 8.3

Go to solution
Frequent Advisor

User(s) transfer from 7.2 to 8.3


We are in the process of going from OpenVMS 7.2 to 8.3. Rather than having to create all new users again on 8.3, is it possible to copy over all the users (or selected users) to the new OpenVMS 8.3 system?

Regards and Thanks,
Kris Clippeleyr
Honored Contributor

Re: User(s) transfer from 7.2 to 8.3

You're talking about 2 separate systems?
If so, you could just copy the SYSUAF file from the 7.2 system to the 8.3 one; or if you have to selectively move the user accounts, have a look at QUAI (to be found on our website: http://www.quadratrix.be/quai.html )

Kris (aka Qkcl)
I'm gonna hit the highway like a battering ram on a silver-black phantom bike...
Ian Miller.
Honored Contributor

Re: User(s) transfer from 7.2 to 8.3

copy the SYSUAF and the RIGHTSLIST - no compatibility issues.

Take the opportunity to rationalise.

Purely Personal Opinion
Jan van den Ende
Honored Contributor

Re: User(s) transfer from 7.2 to 8.3


We are in the process of going from OpenVMS 7.2 to 8.3.


If upgrade, you are there already. Well, nearly. Carefully read through the Release Notes for any instruction for new minimum values, then check and, if necessary, adjust. It usually pays to regard MINIMUM as scrappy, and be a bit more generous.

If new install, like Ian said, just copy.
But that is only one part.
You also have to get the user directories in place, with the right ownership and protection.
Best, and least error-prone, method would be to restore (BACKUP/OWN=ORIG) the thevice that held the user dirs of the old system.
( keep an eye on optimising the device params. First INITing with params more approprite to modern device, like /CLUSTER=(multiple of 16), and then BACKUP/NOINIT)



Have one on me.

Don't rust yours pelled jacker to fine doll missed aches.
Craig A Berry
Honored Contributor

Re: User(s) transfer from 7.2 to 8.3

If you copy SYSUAF.DAT and RIGHTSLIST.DAT, you'll also potentially need VMSMAIL_PROFILE.DATA and NETPROXY.DAT, depending on whether you use those on your old system.

There are potential gotchas to either merging records or copying the files in toto.

Be careful not to clobber accounts on the new system that you may need. For example, if the new system is already up and running and you're using TCP/IP Services to telnet in, then you probably have a TCPIP$TELNET account that was automatically created when you enabled the service. If you have such an account on the old system, it may not have appropriate quotas or the correct (auto-generated) UIC to function on the new system. If you don't have such an account on the old system, a complete copy of SYSUAF.DAT effectively removes the account from the new system. Any software you've installed on the new system might have one or more associated accounts that could run into the same problem.

When we moved from Alpha v7.1 to Itanium v8.3-1H1 about a year and a half ago, I dealt with this by writing a Perl script that merged records but maintained an exclusion list specific to our environment so the relevant accounts on the target system would not be touched. The advantage of a merge rather than copy was that I could do a preliminary conversion for testing and then a final merge that picked up any new or changed accounts.

Be sure to rethink quotas. The DEFAULT account on your new system probably comes with quotas that are too small. If you replace it with the DEFAULT account from the old system, then the quotas will be really, really too small. Each new account you create on the new system will then inherit the tiny quotas from the old system. And all the existing account quotas that you move across may need revisiting. I handled this by creating a template account and then writing a program that upgrades quotas on a target account based on the template. The program is available here:


QUAI looks interesting, especially if you're just migrated a small number of selected accounts. Wish I'd known about it.

I also made extensive use of Joe Meadows' UAF utility. It doesn't merge anything but is very useful for rooting around and seeing what you've got. You may find you have some accounts that you really don't want to bring forward to the new system, or you may find accounts that are in active use that you didn't know you had and might otherwise miss in the migration. I recently updated UAF and made it available at:

John Gillings
Honored Contributor

Re: User(s) transfer from 7.2 to 8.3


The files are compatible. Make sure you check ALL the system "personality" files, and consider interdependencies (like SYSUAF and RIGHTSLIST). See SYLOGICALS.TEMPLATE for the most complete list.

One thing to beware of when migrating UAFs between systems - changes over time in quota costs and requirements. Too often UAFs which were compiled in the dim and distant past have quotas which were appropriate at the time, but have gone out of date.

For example, a UAF originating on a small VAX in the early 1990's now in use on a modern Itanium system with orders of magnitude more resources, may unnecessarily constrain users with inappropriatly small WSQUOTA and/or PGFLQUOTA.

It's worth dumping out a UAF list and eyeballing the quotas to see if anything needs increasing for the new environment.
A crucible of informative mistakes
Andy Bustamante
Honored Contributor

Re: User(s) transfer from 7.2 to 8.3

Upgrade or new installation?

An upgrade will preserve your existing user files. You could also restore a backup of your present system and upgrade in place to 8.3, assuming your're going from Alphaserver to Alphaserver.

If you don't have time to do it right, when will you have time to do it over? Reach me at first_name + "." + last_name at sysmanager net
Robert Gezelter
Honored Contributor

Re: User(s) transfer from 7.2 to 8.3


In essence I agree with John.

For sites with more than a handful of accounts, I tend to move the existing UAF, RIGHTSLIST, and other files to the new system. However, I save the corresponding files created during the installation process and verify that the automatically created accounts are either the same on both systems, or the quotas have been updated to the new values.

(Note to OpenVMS Engineering: It would be a good idea for the various startup scripts to verify quotas and related settings and issuing appropriate messages, rather than creating obscurities at later points.)

When necessary, I use command procedures that from a UAF listing to bring quotas up to date using the AUTHORIZE MODIFY command.

Temporarily, one can use process minimums on a system-wide basis, but there are dangers in that approach.

- Bob Gezelter, http://www.rlgsc.com
John Gillings
Honored Contributor

Re: User(s) transfer from 7.2 to 8.3


> Note to OpenVMS Engineering

I've been trying for years to convince OpenVMS Engineering that OpenVMS should have a lot of sanity checks on reboot. Things like cluster configuration, queue configuration, quotas, etc... so many things that can be silently wrong until the worst possible time, and would be so trivially easy to check.

Big bruise in middle of forehead from banging my head against that brick wall.

I suppose it keeps support folk in jobs :-(
A crucible of informative mistakes
Shriniketan Bhagwat
Trusted Contributor

Re: User(s) transfer from 7.2 to 8.3


Along with the above recomendations from others, refer the below link for upgrading/installing the V8.3 OS.


Craig A
Valued Contributor

Re: User(s) transfer from 7.2 to 8.3

Are you moving the users to new tin?

If so, I wouldn't ship anything but provide new.

Use it as an opportunity to rationalise and strip out all the crud that will have gathered on the system over the years.

Use new physical device names, logical names, usernames (possibly a new VMS username standard), etc..

Honored Contributor

Re: User(s) transfer from 7.2 to 8.3

Given that there's no f$getuai DCL lexical function, here's the GETUAI tool, a tool that extracts the specified UAF record contents into DCL symbols, and which could be the basis for a locally-written migration procedure:


if you'd prefer to get out of the business of adding and maintaining this stuff and allow folks to enroll themselves and allows them to reset their own passwords, here's the NEWUSER tool:


If you do decide to port over the contents of the core authorization files in bulk, do expect to have to resolve the inevitable UIC and binary identifier values collisions; these tend to collide. (This wouldn't be my preferred approach, but I've used it.)

Here are the list of files that are shared, and that can have either host or usernames or UICs or identities embedded:


That's likely a few more files than you will have to deal with here, but it's a start, and it describes the files that are shared in a cluster.

As for cleaning off stale identifiers in file ACLs and such, here's an ACL_SCRUB tool:


Here's a general write-up on creating OpenVMS users:


And as Craig A comments, I'd start over again and haul over as little as possible, if that's at all feasible. VMS systems tend to build up huge accretions over the years, odd defaults and settings, weird logical names and all that dreck makes the management more complex, and can lead to higher direct and indirect support costs. (You can end up paying for the support for products and licenses that you aren't using anymore, for instance.)
Jeremy Begg
Trusted Contributor

Re: User(s) transfer from 7.2 to 8.3

Hi Niall,

I've also had to deal with the problem of moving a batch of users from one system to another. Copying SYSUAF and RIGHTSLIST is one method but I prefer to merge the old and new instead.

First you need to confirm that the users to be moved don't have UICs which conflict with any existing users on the destination server. (In your case it sounds like you're building a new server so this shouldn't be a problem.)

Secondly you need to get a list of all the Rights Identifiers on the existing system using


which will create RIGHTSLIST.LIS. Armed with this information, create the Identifiers on the new system. It's best if you can preserve the identifier values otherwise you risk breaking any ACLs which might be present in your filesystem.

Then to move the users I use EDIT/TPU to edit the SYSUAF.DAT file from the old system, removing the users which aren't going to be moved, then saving the file to (say) USERS.TXT. I copy USERS.TXT to the new system then merge it into the UAF there using


The next step is to create rights identifiers for all the moved users. The ADD/IDENT/USER= command within AUTHORIZE is the easiest way, in my experience.

Once the user Rights Identifiers are created you need to grant any other Identifiers to each user. Use the RIGHTSLIST.LIS file to guide you. (If you're good at TPU it's not hard to turn this into a list of GRANT/IDENT commands.)

Other steps might include moving the users' directories using BACKUP (unless the disks are being moved from the old machine to the new) and possibly changing the users' default device and directory in SYSUAF.

Jeremy Begg