Right-list database

[Niall Ward]

Can anyone provide me with the command to copy the right-list database from one system to another to include the logical locations. e.g. copy/lo jane::location&file mary::location.
Thanks,
Niall.

[Ian Miller.]

as the rightslist database is always open I use
$ CONVERT/SHARE RIGHTSLIST newplace

[Niall Ward]

Thanks for the quick reply, but where is the new place logically speaking. is it just sys$system. Also what is the name of the file. I just want to copy it from one disk to another on the same box

[Art Wiens]

Typically you would find it in:

$ dir sys$system:rightslist.dat

Directory SYS$COMMON:[SYSEXE]

RIGHTSLIST.DAT;1 ... however, you may have a logical defined on your system, enter a :

$ show logical rightslist /full
"RIGHTSLIST" [super] = "SYS$SYSTEM:RIGHTSLIST.DAT" (LNM$PROCESS_TABLE)

Chances are, you will not be able to copy the file, have a look at this thread that I had asked about...lots of good help was provided to me.

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=213453

What problem are you trying to solve?

Art

[Hein van den Heuvel]

The 'right' way to find out the name/place of rightslist.dat (and sysuaf and vms$mail_profile ...) is to use something like:

f$parse("rightslist","SYS$SYSTEM:.DAT",,,"SYNTAX_ONLY")

This will follow the logical if it is there and it will provide the default sys$system location and .dat name extension if the logical was not there.

hth,
Hein.

[Antoniov. · Accepted solution]

From source host (look at semicolon at end of command):
$ COPY/LOG SYS$SYSTEM:RIGHTSLIST.DAT -
remhost"remuser rempwd"::SYS$SYSTEM:*.*;

From target host (look at semicolon at end of command):
$ COPY/LOG srchost"srcuser srcpwd"::SYS$SYSTEM:RIGHTSLIST.DAT -
SYS$SYSTEM:*.*;

Perhaps you could meet sharing problem, so it's possible you must copy file using backup:
From source host:
$ BACKUP/IGN=INTERLOCK - SYS$SYSTEM:RIGHTSLIST.DAT -
SYS$SYSTEM:MYRIGHT.DAT
$ COPY/LOG SYS$SYSTEM:MYRIGHT.DAT -
remhost"remuser rempwd"::SYS$SYSTEM:RIGHTSLIST.DAT;


From target host (after command BACKUp on source host):
$ COPY/LOG srchost"srcuser srcpwd"::SYS$SYSTEM:RIGHT.DAT -
SYS$SYSTEM:RIGHTSLIST.DAT;

Antonio Vigliotti

[Antoniov.]

Oops,
I've forgot:
You must have same user in SYSUAF.DAT !!!!

Antonio Vigliotti

[Hein van den Heuvel]

Antonio,



I respectfully dissagree with all you advice in teh prior replies.

> From source host (look at semicolon at end of command):
$ COPY/LOG SYS$SYSTEM:RIGHTSLIST.DAT -
remhost"remuser rempwd"::SYS$SYSTEM:*.*;

It might work, but it is WRONG.

The real rightlist may be a logical and does not have to live in sys$system. Furthermore there may well be a stale/old rightslist in sys$system making it _seem_ to work.


> $BACKUP/IGNORE=INTERLOCK.

It might work, but it is WRONG.

Why run the risk of picking up an inconsistent state of the file when there is a perfectly safe alternative, as replied earlier.
Use: CONVERT/SHARE

>> $ COPY/LOG srchost"srcuser srcpwd"::SYS$SYSTEM:RIGHT.DAT -
SYS$SYSTEM:RIGHTSLIST.DAT;

Are you sure you want to blow away any and old rightlist data from the target?
You may want to consider CONVERT/MERGE/EXCEP=problems source target
(You'll problable need a conv/share copy from the target to do this on).
If you really want to get fancy you could consider a DCL loop. Untested:

$Open/read/share=write remote remote::...
$Open/read/write/share=write local 'f$parse("RIGHTLIST","SYS$SYSTEM:.DAT",,,"SYNTAX_ONLY")
$Open/write exception exception.dat
$Loop:
$read/end=done remote record
$key = f$extr(record,16,32)
$read/key=&key/erro=insert local dummy
$write sys$output "record exists for : ",key
$write/symbol record exception
$goto loop
$insert:
$write/symbol record local
$goto loop
$done:
$close...



Regards,
Hein.

[Uwe Zessin]

I would _not_ blindly copy to 'SYS$SYSTEM:'! If RIGHTSLIST is not defined, then I would copy to "SYS$COMMON:[SYSEXE]".

[Antoniov.]

Hein,
usually I agree with but now I've a differente idea form you :-(

The real rightlist may be a logical and does not have to live in sys$system. Furthermore there may well be a stale/old rightslist in sys$system making it _seem_ to work.

You hint use f$parse("RIGHTLIST","SYS$SYSTEM:.DAT",,,"SYNTAX_ONLY")
but this function return the real name of rightslist in SYS$SYSTEM without check for existence (as SYNTAX_ONLY parameter says); however if rightlist is a logical name I guess it contains directory and type of file or else return the real name of SYS$SYSTEM:RIGHTSLIST.DAT. Howver it's very simple to test.

About backup we have already discussed in the past: you have right when say "don't use /IGN=INTER" and I known this don't grant full file integrity; I presumed RIGHTSLIST is not continuosly modified but it's only opened for write.

Your procedure merge 2 rightslist files (I posted warning about different user list) but I thing doesn't work because AFAIK the function f$extract has different syntax

Regards
Antonio Vigliotti

[Hein van den Heuvel]

Niall asked:
>Thanks for the quick reply, but where is the new place logically speaking. is it just sys$system

The new place typically is SYS$COMMON:[SYSEXE]RIGHTSLIST.DAT, but you have to watch out for logical names, so do a show log first and use the f$parse hint for automated procedures.

By using f$parse("RIGHTSLIST","SYS$SYSTEM:.DAT) you'll be doing the same thing as loginout and authorize are doing. You tell rms to use rightslist as a logical first and then fill in any missing filespec components from SYS$SYSTEM: and the extension .DAT. This ensures that if it also works if it is not a logical because the result will be sys$system:rightslist.dat
I believe 'syntax_only' is appropriate, but it could be wrong.

Indeed, backup/igno=interlock on rightslist will generally work. But it is the wrong mindset and can lead to you cases where it does not work. The real danger for /ign=interlock lies in end user application which are using 'deferred write' there the timing window is not just the time for RMS to do a series of IOs, but it can be an end users getting a cup of copy or leaving the application open over night.

My procedure was a guideline only. 'untested' as indicated. Just a brain dump top down, no looking back. I may well have gotten f$extr wrong.. I always get that one wrong :-). A procedure along these line can help you decide whether you are doing a reasonable thing or creating a mess.


COPY to SYS$SYSTEM in cluster is tricky as you may well end up in sys$specific where sys$common was intended and visa versa. It is good to use /LOG like Antonio suggests to get immediate feedback.


Hein.

[Anton van Ruitenbeek]

Niall,

As posted before: RIGHTLISTS and SYSUAF are tricky to copy. We copy this file using BACKUP/IGNORE=INTERLOCK and for us: so far, so good.
But these files are node specific. In a cluster (ofcourse) clusterspecific. The RIGHTLISTS holds also identifiers per node (SYS$NODE_) etc. The value of these identifiers are also different. These are created as first come, first get. User identifiers are UIC based. But by installing products some identifiers are also (default) created as first UIC come, first get. Mixing these up can give you a lot of work to correct these.
Mixing RIGHTLISTS can give you a lot of fun on ownerships and rights on al of you're disks. Also the RIGHTSLISTS must be in SYS$COMMON:[SYSEXE] or pointed with a executive system/cluster logical RIGHTLISTS. When activating the right one, the queueumanager must be restarted etc. etc. DECNet also opens the RIGHTLISTS until next restart etc.
We were very lucky during the rolling upgrade from 7.2-2 to 7.3-1. We had users with more then 100 identifiers. Because of a bug in $GETJPI, if these users login, the system crashes. After knowing the problem we temporary removed a lot of identifiers of these users and the bug is or will be fixed right now. During this proces (crashes etc.) our SYSUAF and RIGHTLISTS files become corrupted (actualy the drive become corrupt, so we had more problems. But we are talking here about SYSUAF and RIGHTLISTS). I can tell you beautifull stories about these weeks :-((. But because the systems may not go down (the users who were logged in, keeps on working) we had a hard strugle to get those files from backup (after several times we kept these files somewhere on the disk) and get in the right places and proper restart of processes (eq. DECNet, queuemanager)

Don't forget: The rights which the user has, are connected to a UIC identifier, not to a username. Only normaly you create a UIC identifier equal to the username with the same UIC, so it looks like the extra right-identifiers are connected to a username !!

AvR

[Willem Grooters]

Niall,

Do you have a recent backup of these files on JANE? Then restore these ones on MARY (when noone else is using the system).

if JANE and MARY are nodes in one cluster, you could try to solve it another way as described before. Perhaps it will work outside the custer as well, as long as both machines are connected on Decnet.

Given the fact you want the rightslist on JANE to be used on MARY as well, you just have to specify on MARY where the rightslist is. Since rightslist.dat (= autorization) and sysuaf.dat (athentication) are closely related, you should also do likewise for sysuaf:

$ DEFINE/SYSTEM/EXEC RIGHTSLIST JANE::SYS$SYSTEM:RIGHTSLIST.DAT
$ DEFINE/SYSTEM/EXEC SYSUAF JANE::SYS$SYSTEM:SYSUAF.DAT

(This may lead to problems in accessing the files when the requestor has no acess to JANE - i think a proxy for MARY::SYSTEM will be required on JANE, but no doubt others will comment on that)

Whatever method you use: be aware that files access and security are linked to RIGHTSLIST.DAT as well, which can render files inaccessable due to missing identifiers.

Willem

[labadie_1]

Willem

even not in a Cluster, I have already done
$ def sysuaf remnode"user pass"::sysuaf
(this supposes the logical name sysuaf is definedon remnode)
$ mc authorize mod user/xxx
$ deass sysuaf

Of course, if you do not want to put the string user /password, you will need a proxy