Change Nodename and DECnet Address in DECnet Plus

[John Welsh_2]

Hi all,
How do I change the Nodename and DECnet address
in DECnet Plus ( DECnet OSI) ? Is it a simple matter of running a command procedure or do I have to edit an existing NCL script to do
this ? I started to read through the manuals but they are kind of unfriendly.
Thanks.

[Heinz W Genhart]

Hi John

You have to change SCSNODE and SCSSYSTEMID in Modparams.dat, do Autogen and reboot.
After the reboot you have to use
@sys$startup:net$configure advanced

to change the DECnet Nodename and Address.


Regards

Heinz

[Wim Van den Wyngaert]

And if it's not working try mc ncl flu ses con nam cac ent "*".

Wim

[Andreas Vollmer · Accepted solution]

Hi John,

Please refer to the OpenVMS FAQ maintained by HP about how to rename a system.
This helps to avoid pitfalls.
The previous entries from the colleagues are total correct!

Here is the extract of the mentioned FAQ from HP:
Section 5.6
How do I change the node name of an
OpenVMS System?
The first step is to get a BACKUP of the system disk before making any changes---use the system disk backup procedures as documented in the OpenVMS System Management Manual, making sure to use the procedures and commands appropriate for the system disk.
Changing the node name involves a number of steps---the node name tends to be imbedded in a number of different data files around the system.
â ¢ Update the SCSNODE in MODPARAMS.DAT, and then run AUTOGEN as far as the SETPARAMS phase. (Do not reboot yet.)
â ¢ Modify the DECnet node name. (NETCONFIG is the DECnet Phase IV tool, and NET$CONFIGURE is the DECnet-Plus tool.)
â ¢ Modify the IP node name. (The TCP/IP Services tool is UCX$CONFIG prior to V5.0, and is TCPIP$CONFIG in V5.0 and later releases.)
â ¢ Modify the host node name on the various queues in the queue database. (each queue has a host name, and it defaults to the SCS node name of the queue's host system. See the command INIT/QUEUE/ON=node for information.)
â ¢ Modify the node name saved in any application databases, or any local node-conditional operations present in the site-specific system startup, etc. (SEARCH for the node name, specifying all types of files.)
â ¢ Use the AUTHORIZE utility command RENAME/IDENTIFIER to rename the SYS$NODE_oldnodename rightslist identifier to match the new node name. (Do not change the binary value of this identifier, and do not delete the identifier.)
If you have erroneously deleted or duplicate the identifier, you can locate existing references to the binary identifier value using the Freeware DFU package, and specifically the commands SEARCH/ACE and /OWNER. You must (re)create the correctly-named identifier using the binary value that is often stored in various Access Control List Entry (ACE) structures and object owner fields associated with files and objects present in the OpenVMS system.
â ¢ Reset any license PAKs that are restricted to the old node name to the new node name.
â ¢ If the node name is part of a disk volume label, see Section 5.12.
â ¢ Reboot the node or---if in a VMScluster---reboot the whole VMScluster. (This tends to catch any errors immediately.)
There are likely a few other areas where the nodename will be stored.
If the system is configured in a VMScluster and you change either the SCSNODE or the SCSSYSTEMID---but not both values---then you will have to reboot the entire VMScluster. (The VMScluster remembers the mapping between these two values, and will assume that a configuration problem has occured if a mismatched pair appears, and will refuse to let a node with a mismatched pair join the VMScluster.)
To calculate the correct SCSSYSTEMID value, multiply the DECnet Phase IV area number by 1024, and add the DECnet Phase IV node number. For example, the SCSSYSTEMID value for a DECnet node with address 19.22 is 19478. ((19 * 1024) + 22 = 19478)
This may well have missed one or two configuration tools (or more!) that are needed at your site---the node name tends to get stored all over the place, in layered products, and in local software...

By the way...
to decode Wim's suggestion ;-)
mcr ncl flush session control naming cache entry "*"

Ciao
Andreas

[Jan van den Ende]

John,

Andreas wrote:

There are likely a few other areas where the nodename will be stored.
If the system is configured in a VMScluster and you change either the SCSNODE or the SCSSYSTEMID---but not both values---then you will have to reboot the entire VMScluster. (The VMScluster remembers the mapping between these two values, and will assume that a configuration problem has occured if a mismatched pair appears, and will refuse to let a node with a mismatched pair join the VMScluster.)


VERY true! Even so much so, if this has happened, you wil NEVER be able to enter any of the mismatched ID's or names to THIS cluster. Correcting the mismatch wil NOT help, you WILL reve to shut down the cluster, and form a new one.
_OR_, you might cheat, and decide to declare ALL out-of-sync names and IDs as used-up, and set up an entirely new name-ID pair (and consequently, DECnet node address). Your network staff may not like this, but otherwise it is a pretty easy workaround.

Proost.

Have one on me.

jpe

[John Welsh_2]

Thank you everyone - the replies were extremely helpful. I was able to do what
was needed.

[John Welsh_2]

The answers were exactly what I needed