SYSUAF File Merge

[Mario Abruzzi]

Is there an easy way to merge two SYSUAF files that are about 20% different? The only way I can think of is to use SORT/MERGE on text listings of these two files and merge them manally. Is there a more efficient way?

[Uwe Zessin]

Define 'different'.

In the past I pulled the files into a text editor and deleted any records I did not like. Although the contents are mostly binary it was easy for me, because the username is almost at the left side. Next I wrote out the remaining records which creates sequential files.

That can be easily fixed by creating an FDL file from the original SYSUAF ($ANALYZE/RMS/FDL) and simply converting.

Beware of duplicate UICs and rememeber that rightslist identifiers are in RIGHTSLIST.DAT, which is permanently kept open.

[Hein van den Heuvel]

You can convert/merg multiple sysuaf (or any other indexed file) directly.

Fear not! (but make tests on copies first :-).

Be sure to use /excep and /stat

And you may want pass your favourite sysuaf.fdl for the output.


sysuaf is just an indexed file which can be tuned, merged, optimize like any other.

Except... that it is open most of the time.
For that reason I like to :
- practice with a conv/shar copy first.
- convert[/share] to sysuaf.new
- rename [/log] to sysuaf.dat
- rename the old file to .old


Enjoy!
Hein.

[Volker Halle · Accepted solution]

Mario,

this is documented in the OpenVMS Cluster Systems Manual appendix B

http://h71000.www7.hp.com/doc/72final/4477/4477pro_023.html#build_uaf_upgrade

As Uwe already said, it needs some planning ahead, not only for username, but also for identifiers.

I once wrote a simple DCL procedure for copying individual user's records from one SYSUAF to another:

$!
$! COPY_USER.COM - copy SYSUAF record for user to another SYSUAF file
$!
$ ON CONTROL_Y THEN $ GOTO eof_s
$ OPEN/READ s SYSUAF.DAT ! source SYSUAF file
$ OPEN/READ/WRITE/SHARE new NEW_SYSUAF.DAT ! use existing dest UAF file
$!
$loop:
$ READ/END=eof_s s line
$ user = F$EXTRACT(4,32,line)
$ SHOW SYMB USER
$ INQUIRE c "Copy user"
$ IF c .EQS. "YES"
$ THEN
$ WRITE/SYMBOL new line
$ ELSE
$ WRITE SYS$OUTPUT "... not copied ..."
$ ENDIF
$ GOTO loop
$!
$eof_s:
$ CLOSE s
$ CLOSE new

It could be used, if you just want to copy some individual users.

Volker.

[Martin Vorlaender]

Hi,

as often with OpenVMS, it's not really the question whether something is documented but rather where it is...

This particular one is well hidden in Appendix B of the Cluster manual, see
http://h71000.www7.hp.com/doc/731FINAL/4477/4477pro_023.html#build_uaf_upgrade

[Ian Miller.]

sort/merge on SYSUAF is fine.

Check for duplicate UIC and add the required records to the rightslist with ADD/ID afterwards.

I have had trouble with merging RIGHTLIST files - I think it is due to the more complex index or something.

[Jan van den Ende]

Ian,

more probable cause of trouble with merging RIGHTSLIST is the default behavior of ADD/IDENT: it just generates the next-available value and assigns that to the new name.

If you didn't add a /VAL= , and made sure you gave equal values to equal names, and different values to different names, then there is the source of your merging trouble.

Looooong ago ( 1980's somewhere), we found it worthwile to devise an algorithm to couple names to values vv., and I have been lucky enough to be able to enforce it at any "new" site I came to work at (largely because the use of identifiers is not very wide-spread, I guess).

We even have a practise that IF an installation DOES add a (numeric, as opposed to UIC-format) identifier, which we of course detect on our test system, then we de-install, remove the ident, calculate the value according to our algorithm, and pre-define it on any system before the installation.
Works great!

fwiw

Cheers.

Have one on me.

Jan

[Rick Dyson]

This topic is of specific interest to me now. I want to migrate for one cluster to another and need to make the SYSUAF change as easy as possible.

There are lots of layered product installs now (TCPIP has lots and some are new as compared to the old system I have).

The new, clean cluster install has more and newer versions and the old SYSUAF has thousands of users. Not lots of RIGHTSLIST ids, but some.

Everyone mentions "editing" the SYSUAF. Could anyone be explicit for a dumby? :) Exactly which editor and/or qualifiers, for example. Then once I have the file open in front of me, will it be obvious what "record" I want to cut from the new to overlay on the old copy to get it working right? Or insert into old copy new accounts that did not exist, etc.

My plan would be to start with a copy of the old system and then insert or replace in it any entries I have in the new SYSUAF.

Thanks!
Rick

[Ian Miller.]

I would start with the new uaf and add in the usernames from the old uaf using the DCL listed previously. This way the DEFAULT username and the usernames from the layered product installations will be correct for that system.

[Arch_Muthiah]

Mario,

$ CONVERT SYSUAF1,SYSUAF2,...SYSUAFn MASTER_SYSUAF

the above CONVERT utility can also be used to merge any SYSUAF to your Master SYSUAF.DAT files.

This CONVERT usage is mentioned in "OpenVMS Record Management Utilities Reference Manual".

Note that if a given user name appears in more than one source file, only the first occurrence of that name appears in the merged file.

Example: The following command sequence example creates a new SYSUAF.DAT file from the combined contents of the two input files:

$ SET DEFAULT SYS$SYSTEM
$ CONVERT/MERGE [SYS1.SYSEXE]SYSUAF.DAT, -
_$ [SYS2.SYSEXE]SYSUAF.DAT SYSUAF.DAT

After you run CONVERT, you have a master SYSUAF.DAT that contains records from the other SYSUAF.DAT files.


Archunan

[Rick Dyson]

Thank you both! (opps, I won't be able to give points!)

I found the appendix that mentions the merging with CONVERT. It does seem to work so far. The RIGHTSLIST does not seem to be quite as forgiving. It keeps duplicates as far as I can tell. Two names with the same ID or UIC. I am tidying up manually.

I will have to do this for real just before the conversion from the old to new systems so I don't loose too much info and changes from the production SYSUAF (login times and password changes by users). There will be a "no changes after a certain time" line where I will fetch the file to the new system before we go off-line.

I am assuming the RIGHTSLIST and NETPROXY/NET$PROXY files are pretty static and would not be changing, right? As long as I am not doing anything!

rick

[Uwe Zessin]

The problem with RIGHTSLIST is that it is usually permanantly open. What I did in the past was - use a text editor and cut&paste the records I wanted; it is pretty obvious from the contents. Write to a sequential file and do a CONVERT/FDL afterwards.

If you screw it up - complain to _NLA0: ;-)