SYSUAF

[The Brit]

Check that your SYLOGIN.COM is the same on both systems, it can be found in Sys$Common:[SYSMGR].

Also check your account in SYSUAF.DAT. At the top on the left, there is a field called "LGICMD" which will normally indicate the name of the User's Login File. If this file exists on your production side, it must also exist on your standby node, and must contain the same stuff.

I should mention that if your "standby" is really a standby, then there are many other files which need to be kept synchronized - startup files for example, Queue Manager DB files, etc.

Dave

[Steven Schweda]

> Is there any way to change all users to
> point to this device? (easily)

Define "easily".

Around here, users (mostly I) have SYSUAF
settings like this:

Default: HOME_SMS:[SMS]

where HOME_user-name is a logical name:

ALP $ show logical /full home_sms
"HOME_SMS" [exec] = "ALP$DKA0:" (LNM$SYSTEM_TABLE)

which is defined at system start-up, in a
node-specific command procedure, so it can be
anything one might like, anywhere one might
like it.

> I set up a logical pointing $1$dka6: to
> dra2: but this didn't work.

That's what you _think_ did. Now, perhaps
you could disclose what you _actually_ did,
and how you decided that it "didn't work".

[Hoff]

Other folks have discussed the direct approach here; replicating the SYSUAF file and setting up the logical name for SYSUAF.

Here are some variations to what has been discussed in other replies, and some background on how some of these pieces work, and work together. And sometimes don't work.

If you're just looking to synchronize passwords, you can trump the whole password replication and synchronization discussion using LDAP on V8.3 or with one of the other external authentication mechanisms; your passwords can be sitting in a remote Active Directory or Open Directory store. Intro:

http://64.223.189.234/node/359

SYSUAF is just one part of the authentication environment. If you're not (also) keeping the UICs lined up, you can end up with access incorrectly blocked or incorrectly not blocked. See the section on merging here:

http://64.223.189.234/node/169

If you're replicating, you need be aware of UICs and identifiers, too. Tool:

http://64.223.189.234/node/426

Regardless, the best approach here is to cluster. That gets you the selective use of your hot-spare as part of your production environment, and both hosts are continuously current. Yes, the cluster licenses are expensive.

And by coincidence, I'm writing some C code in this same basic area this week, and have code that replicates the SYSUAF data over into another database.

[Peter Clarke]

the command i ran was:

define/sys $1$dka6: dra2:

[Steven Schweda]

> the command i ran was:
>
> define/sys $1$dka6: dra2:

That's a start. I'd probably start with
something more like:

define /system /executive_mode $1$dka6 dra2:

and then I might consider answering the part
about:

> [...] how you decided that it "didn't
> work".

Showing actual commands with their actual
output is often more helpful than vague
descriptions and/or interpretations.

[Robert Gezelter]

Peter,

There is almost never a good reason to use an actual device name, except in an actual MOUNT command.

In this case, the most probable best answer is to use the DISK$xxx name created when the disk is MOUNTed.

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

[Joseph Huber_1]

Since this rerouting of devices should only be a temporary solution, change all users home device to use the same logical name on both systems.
To answer Your question
>> Is there any way to change all users to point to this device? (easily)

Well, since $getuai has no way to use wildcard user names,
the simplest is to use the output of
Authorize list/brief (->sysuaf.lis), and process with a command procedure like this:

$! record position of authorize list/brief:
$ _S_owner = 0
$ _L_owner = 19
$ _S_username = 20
$ _L_username = 15
$ _S_uic = 36
$ _L_uic = 12
$ _S_account = 49
$ _L_account = 8
$ _S_privs = 59
$ _L_privs = 7
$ _S_pri = 67
$ _L_pri = 2
$ _S_devdir = 69
$ _l_devdir = 20
$!
$ open/error=exit uaf sysuaf.lis
$ read/end=done uaf line
$LOOP:
$ read/end=done uaf line
$ owner=f$edit(f$extract(_S_owner,_L_owner,line),"TRIM")
$ username=f$edit(f$extract(_S_username,_L_username,line),"TRIM")
$ uic=f$edit(f$extract(_S_uic,_L_uic,line),"TRIM")
$ account=f$edit(f$extract(_S_account,_L_account,line),"TRIM")
$ privs=f$edit(f$extract(_S_privs,_L_privs,line),"TRIM")
$ pri=f$edit(f$extract(_S_pri,_L_pri,line),"TRIM")
$ devdir=f$edit(f$extract(_S_devdir,_L_devdir,line),"TRIM")
$ if f$edit(devdir,"UPCASE,COMPRESS").eqs."DISUSER"
$ then
$ write sys$output "User ",username," is disabled: no dev:[directory]!"
$ dev=""
$ dir = ""
$ else
$ dev=f$parse(devdir,,,"DEVICE","SYNTAX_ONLY")
$ dir=f$parse(devdir,,,"DIRECTORY","SYNTAX_ONLY")
$ endif
$ if dev.eqs.p1 then authorize mod 'username'/device='p2'
$ goto loop
$DONE:
$ close uaf
$EXIT:
$ exit

Assuming AUTHORIZE :== $AUTHORIZE
Call this as "@thisone olddevice newdevice" .

[Paul Jerrom]

Howdy,

The reason the DEFINE didn't work is because you have it the wrong way around! You are wanting to set up a logical called DRA2, not a logical called $1$DKA6 (or whatever your value is).
Format is DEFINE/SYSTEM logical-name value
so you want define/sys dra2 $1$dka6
(make sure you deassign/sys the logical name you erroneously set up otherwise you'll have a logical name translation loop)

BTW, all my systems do NOT have the user's login device hardcoded, all use logical names - ie USERDISK.

Have fun,

PJ

[Paul Jerrom]

Oopsie, re-reading the thread shows it was me that got the define around the wrong way - sorry!!

But comment re. logicals cf device names still applies.

PJ

[AEFAEF]

Paul wrote

"Format is DEFINE/SYSTEM logical-name value
so you want define/sys dra2 $1$dka6"

No! Always use a colon in the equivalence name if it is a device or another logical name that is DEFINE-ed to be part of a file-spec. (OTOH, omit the colon for queue names, forms, and characteristics; mail addresses; data [as in "$ DEFINE EVE$KEYPAD EDT" and such[; etc.)

$ DEFINE/SYSTEM DRA2 $1$DKA6:

or $ DEFINE/SYSTEM $1$DKA6 DRA2: ! whichever it is !

Omitting the colon causes problems in certain cases.

For example:

$ SH DEV DSA0

Device Device Error Volume Free Trans Mnt
Name Status Count Label Blocks Count Cnt
DSA0: Mounted 0 OPENVMS062 837135 197 1
$1$DKA0: (IDS15) ShadowSetMember 0 (member of DSA0:)
$
$ DEFINE BLAH DSA0
$ SET DEFAULT BLAH:[SYS0]
%RMS-F-DIR, error in directory name
$ DEFINE BLAH DSA0:
%DCL-I-SUPERSEDE, previous value of BLAH has been superseded
$ SET DEFAULT BLAH:[SYS0]
$ SHOW DEFAULT
BLAH:[SYS0]
$

"BTW, all my systems do NOT have the user's login device hardcoded, all use logical names - ie USERDISK."

I agree. The only place you should use a physical disk name is when you MOUNT the device and define a /SYSTEM logical name in your startup procedures that points to the device.* If you then reference this disk only via the logical name, changing the disk name is easy: you just redefine the logical name to point to the new disk name. This saves you the trouble of changing all disk references in all your code, command proceudres, databases (SYSUAF.DAT, e.g.), and such. You need only redefine one logical name in your startup procedures.

* Alternatively, you can reference DISK$volume_label instead of defining your own logical name. This way the volume label is your core reference.

AEF