topic Re: decnet_register Question in Operating System - OpenVMS

decnet_register Question

The Brit — Thu, 09 Oct 2008 16:34:05 GMT

We are currently moving from Alpha to blades, which, because of our DR config, has required us to use Decnet over IP. We are using the TCPIP Services/DECnet Phase V combination.

My question is this, do I HAVE to register (using DECNET_REGISTER) every node which might be using DECnet communication, given that all of my decnet connectivity is via IP addresses and DNS Host names, and not Phase IV address or nodenames?

Within my configuration, can I get away with just registering myself, i.e. the 'local' node.

thanks \

Dave.

Re: decnet_register Question

Hoff — Thu, 09 Oct 2008 20:12:37 GMT

You will want to register any node you want found via its local name via the local database and (typically) using the decnet_register tool. For those nodes you wish to reach using the IP host name and such, these can be registered via DNS/BIND entries. Etc.

Re: decnet_register Question

Martin Hughes — Fri, 10 Oct 2008 06:08:58 GMT

You definately don't have to have the remote node registered in your local database. You can even set host to an IP address if you want to. If you want to see how node name resolution is happening there are a couple of things you can look at;

$ mc ncl show session control naming search path

$ mc cdi$trace ! do this and then get another session going and set host to a remote node. You will see the process of nodename resolution unfold.

Re: decnet_register Question

Colin Butcher — Fri, 10 Oct 2008 07:45:19 GMT

You only need to register nodes using DECnet transports (NSP or OSI), where you need name to address resolution for the DECnet node names.

From here on I'll assume that you're using LOCAL naming for DECnet and DOMAIN naming for DECnet over IP.

I'll also assume you're using DECnet on the LAN and DECnet over IP across the WAN, or between LANS / VLANS where you only have IP routing as a means to communicate.

With DECnet over IP you've jumped sideways into the IP stack for name resolution using BIND.

So, use DECNET_REGISTER to set up a clean DECnet name to DECnet address lookup for all your nodes that will use DECnet, export that to a file and import it on all the others. That gets you a consistent DECnet naming scheme.

Set your DOMAIN DNS server to be "127.0.0.1" (equates to "localhost") when you set up naming using NET$CONFIGURE in ADVANCED mode. That will cause the DECnet over IP name lookup to use the local BIND resolver, which will first try the HOSTS file, then use the list of DNS name servers you've set up in your IP stack's name resolution nameserver list. Means you don't have to go back to your DECnet configuration if you ever change your IP name servers.

You should make consistent naming changes everywhere. In practice a destination node will accept inbound DECnet-over-IP connections without having all the naming in place, but you'll see "back translate" failures from the naming service until you have the naming consistent.

All you then do is delete the 'old' DECnet style name from the local naming service (using DECNET_REGISTER) and insert the new name into the local HOSTS database, then move it out to your DNS if you ever need to.

You'll also need to flush the naming caches everywhere too. NCL> FLUSH SESSION CONTROL NAMING CACHE ENTRY "*" is what you need.

Don't forget to enable the PWIP driver and allow ports 102 and 399 through the firewalls. You can also control which IP subnets you accept inbound connections from if you're on a recent version (look at the NCL help for the rfc 1006 and rfc 1006-plus (aka rfc 1869) OSI transport templates.

You might find the article I wrote some time ago for the VMS technical journal useful (V5 I think it was) plus some of the slide sets available at www.xdelta.co.uk/seminars

Don't forget that you can test the connectivity without relying on the naming by using things like set host ip$. You can check the naming at each end by looking at the SYS$*NODE* logical names. Beware that proxies work by node fullname, so expect to have to re-add your proxies.

Also use Martin's recommendation to view the whole name resolution process unfolding.

Cheers, Colin (http://www.xdelta.co.uk).

Re: decnet_register Question

Jim_McKinney — Fri, 10 Oct 2008 10:27:05 GMT

As long as you expect that DECnet-over-IP will be the predominant connection method you might as well instruct DECnet to look to domain prior to local for hostname translation if itsn't already set up that way. So using the myplace.com domain from the example of a previous posting of yours, you might create/replace something like the following in SYS$MANAGER and then execute them:

$ CREATE NET$SESSION_STARTUP.NCL
!% Custom Created
!% NCL Script SYS$SPECIFIC:[SYSMGR]NET$SESSION_STARTUP.NCL;
!% 10-Oct-2008
!%
SET NODE 0 SESSION CONTROL MAINTAIN BACKWARD SOFT LINKS TRUE
SET NODE 0 SESSION CONTROL TRANSPORT PRECEDENCE (TP4,NSP)
^Z
$ CREATE NET$SEARCHPATH_STARTUP.NCL
!% Custom Created
!% NCL Script SYS$SPECIFIC:[SYSMGR]NET$SEARCHPATH_STARTUP.NCL;
!% 10-Oct-2008
!%
SET NODE 0 SESSION CONTROL NAMING SEARCH PATH -
([DIRECTORY SERVICE = DOMAIN, TEMPLATE = "*"], -
[DIRECTORY SERVICE = DOMAIN, TEMPLATE = "*.myplace.com"], -
[DIRECTORY SERVICE = LOCAL, TEMPLATE = "*"], -
[DIRECTORY SERVICE = LOCAL, TEMPLATE = "local:*"], -
[DIRECTORY SERVICE = LOCAL, TEMPLATE = "LOCAL:.*"])
SET NODE 0 SESSION CONTROL BACK SEARCH PATH -
([DIRECTORY SERVICE = DOMAIN, TEMPLATE = ""], -
[DIRECTORY SERVICE = LOCAL, TEMPLATE = ""])
SET NODE 0 SESSION CONTROL NAMING CACHE TIMEOUT 30-00:00:00
SET NODE 0 SESSION CONTROL NAMING CACHE CHECKPOINT INTERVAL 08:00:00
^Z

Re: decnet_register Question

The Brit — Thu, 20 Aug 2009 12:46:18 GMT

Thanks for the help.