8. Configuring DECnet Application Services
This chapter describes how to:
· Configure, start, and test DECnet application services
· Map DECnet names to TCP/IP fully qualified domain names
This guide describes how to configure DECnet application services with the NOT-CONFIG utility (MULTINET CONFIGURE /NOT).
Configuring DECnet application services
After installing DECnet application services:
1. Use the MULTINET CONFIGURE /NOT utility to:
a. Set the DECNET-LOADED and PREFER-DECNET-TO-TCP global parameters as required using the SET command.
b. Configure proxies using the ADD PROXY command.
c. If needed, configure objects for local DECnet applications using the ADD OBJECT command.
d. If needed, define a user name and password for MAIL, PHONE, VPM, NML, and other objects you want to work over DECnet application services using the ADD OBJECT command. If you define a user name and password for an object, you may also want to set PROXY NONE on the object.
e. If needed, define name-mappings between DECnet node names and TCP/IP fully-qualified domain names, or name-mappings to force DECnet communication to specified nodes.
2. Add the startup of DECnet application services to your system startup, as shown in the Modifying Your System Startup section.
3. Reboot, or start the software without rebooting, as described in the Starting DECnet Application Services without Rebooting section.
4. If desired, test DECnet application services, as described in the Testing DECnet Application Services section.
Modifying Your System Startup
For VAX and Alpha:
To start DECnet application services at system startup, modify the system startup file so that DECnet application services start before MultiNet. If you are also running DECnet, ensure that DECnet application services start before DECnet. The setting of the DECNET-LOADED global parameter should agree with the lines placed in your system startup. If you change the setting of DECNET-LOADED, you must change your system startup.
If your system is running OpenVMS VAX V5.x, the system startup file is SYS$MANAGER:SYSTARTUP_V5.COM; for all later versions and for Alpha systems, this file is SYS$MANAGER:SYSTARTUP_VMS.COM.
If your system runs both DECnet and DECnet application services:
1. Modify your system startup file so it resembles the following example.
2. Set the global parameter DECNET-LOADED to TRUE (the default).
$@SYS$SYSDEVICE:[MULTINET.nodename.SYSCOMMON.MULTINET]-
_$ START_NOTDRIVER ! Start DECnet application service
$ SYS$MANAGER:STARTNET ! Start DECnet
$@SYS$SYSDEVICE:[MULTINET.nodename.SYSCOMMON.MULTINET]-
_$ START_MULTINET ! Start MultiNet
If your system runs only DECnet application services:
1. Modify your system startup file so it resembles the following example.
2. Remove the reference to @SYS$MANAGER:STARTNET.
3. Set DECNET-LOADED to FALSE (refer to Chapter 8 for a summary of commands).
$@SYS$SYSDEVICE:[MULTINET.nodename.SYSCOMMON.MULTINET]-
_$ START_NOTDRIVER ! Start DECnet application services
$@SYS$SYSDEVICE:[MULTINET.nodename.SYSCOMMON.MULTINET]-
_$ START_MULTINET ! Start MultiNet
Note: DECnet may be shutdown and restarted now if there are no users. This will allow most applications to use DNAs.
Modifying Your System Startup for Itanium
Edit SYS$MANAGER:SYSTARTUP_VMS.COM and start MultiNet where DECnet would normally be started. The MultiNet startup procedure will start MultiNet, load the necessary drivers, and start DECnet if appropriate.
Starting DECnet Application Services without Rebooting
Enable the NOT service, restart the MultiNet Server, and manually start DECnet application services with these commands:
$ MULTINET CONFIGURE /SERVER
SERVER-CONFIG>ENABLE NOT
SERVER-CONFIG>RESTART
SERVER-CONFIG>EXIT
$ @MULTINET:START_NOTDRIVER
$ @MULTINET:START_SERVER
When DECnet application services start after DECnet, certain applications that register as DECnet objects during their startup are not registered with DECnet application services. Until these applications are restarted, any attempt to access these objects over DECnet application services will result in a NOSUCHOBJ error. This includes the DECwindows and CTERM (SET HOST) objects. To guarantee that all objects register with both DECnet application services and DECnet, Process Software recommends you reboot after installing and testing DECnet application services and modifying your system startup command procedure.
Testing DECnet Application Services
Test the DECnet application services installation by using the SET HOST command to connect to your own node and then to a remote node:
· If your system is running OpenVMS V6.1 or later or OpenVMS Alpha V1.5 or later, log into your own node with the SET HOST command as follows:
$ DIR *0”username password”::
An asterisk preceding a host name forces processing by DECnet application services. If this command succeeds, also try:
$ SET HOST *remote_node_name
Note that this requires DECnet application services to be running on the remote node.
· If your system is running an earlier version of OpenVMS, use MULTINET CONFIGURE /NOT to define a NAME-MAPPING to force communication with a test host (for example, SPAM) to use DECnet application services rather than DECnet, SET HOST to test the installation as shown in the following example:
$ MULTINET CONFIGURE /NOT
MultiNet NOT Configuration Utility 5.5(nn)
[Reading in NOT configuration from MULTINET:NOT.CONFIGURATION]
NOT-CONFIG>ADD NAME-MAPPING SPAM LOCALHOST
NOT-CONFIG>RELOAD
Connected to NETCONTROL server on "127.0.0.1"
domain Network Control Mon 13-Mar-2013 7:42am-EST
NOT database reload done
NOT-CONFIG>EXIT
$ SET HOST SPAM
If the SET HOST commands succeed, DECnet application services are working properly and you can remove the test NAME-MAPPING.
Resolving Node Names
Systems running both DECnet and DECnet application services use the following rules when determining whether to use DECnet or DECnet application services:
1. If an asterisk precedes the node name (*nodename), use DECnet application services. (Valid only if the system is running OpenVMS V6.1 or later.)
2. If an underscore precedes the node name (_nodename), use DECnet.
3. If name-mapping is configured for the node and the node is a valid TCP/IP node, use DECnet application services; a host is valid to TCP/IP if it appears in a host table or in DNS.
4. If the node name is a valid TCP/IP node or a numerical IP address, and not a valid DECnet node, use DECnet application services.
5. If the node name is a valid DECnet node and not a valid TCP/IP node, use DECnet.
6. If the node name is valid in both TCP/IP and DECnet, or if you specify the node name as "0," dispatch according to the setting of the global parameter PREFER-DECNET-TO-TCP, which is TRUE by default.
Name Mapping
With DECnet application services and TCP/IP, two translations must occur:
1. The DECnet name must be translated into a fully qualified domain name (a requirement of DECnet application services).
2. The fully qualified domain name must be mapped to an IP address (a requirement of TCP/IP).
By default, the local domain name is appended to the node name to create a fully qualified domain name.
By default, the PREFER-DECNET-TO-TCP setting is set to TRUE, so if the target node is a DECnet node and a TCP/IP node, the connection occurs over DECnet. Setting this parameter to TRUE ensures the connection occurs over DECnet if the target node is both a DECnet node and a TCP/IP node.
To force the connection over DECnet application services instead of DECnet, complete one of the following steps:
· Use the NOT-CONFIG utility to set PREFER-DECNET-TO-TCP to FALSE (the default value is TRUE). Setting this parameter to FALSE causes all connections to be made over DECnet application services if no name-mapping exists.
· If all nodes are running DECnet application services, and if appending the local domain name to the node name always results in the proper, fully qualified domain name for the host (which will occur for almost all networks), you have finished configuring DECnet application services.
· If you set PREFER-DECNET-TO-TCP to FALSE, you can use ADD NAME-MAPPING to force connections to specific nodes to use DECnet. For more information on name mapping, see the Creating a Name-Mapping Database section.
· On versions of OpenVMS that offer fullnames support, specify an asterisk before the node name (*nodename). Use this method only for debugging.
· Map DECnet names to TCP/IP names using DNS.
You can map DECnet names to TCP/IP names in two ways:
|
Using DNS |
To distinguish nodes running DECnet application services from those running only TCP/IP, use a separate subdomain similar to that in the DNAS.FLOWERS.COM examples shown in the Using DNS section. If desired, you can create similar configurations using host table aliases. |
|
Using a name-mapping database |
To distinguish nodes running DECnet application services from those running DECnet, use a name-mapping database as described in the Creating a Name-Mapping Database section. This method is very useful during the initial configuration of DECnet application services; however, the name-mapping database does not scale well in a large DECnet application services network. Process Software strongly recommends using DNS instead. |
Using DNS
DNS maps node names to IP addresses and lets you store information in a central repository and create aliases (called CNAME records) for host names. (For more information on configuring DNS, refer to the MultiNet for OpenVMS Installation and Administrator’s Guide.) By including information for DECnet application services nodes in DNS, you do not need to propagate configuration information to each node so it can translate six-character DECnet names to fully qualified TCP/IP names.
By creating CNAME records for hosts running DECnet application services, and putting the records in their own domain, like node.DNAS.FLOWERS.COM (where node is the six-character DECnet node name), you can easily differentiate between nodes that run DECnet application services and those that do not. When you create a DECnet application services, use the SET DOMAIN-DEFAULT command to point to it. For example:
NOT-CONFIG>SET DOMAIN-DEFAULT DNAS.FLOWERS.COM
Example CNAME records are:
;
; This is a list of hosts running DECnet application services
;
BIRD.DNAS.FLOWERS.COM. IN CNAME Free-Bird.FLOWERS.COM.
CAD.DNAS.FLOWERS.COM. IN CNAME CAD.FLOWERS.COM.
FOO1.DNAS.FLOWERS.COM. IN CNAME Foo-bar.FARAWAY.EDU.
CODEZ.DNAS.FLOWERS.COM. IN CNAME Code-Z.FLOWERS.COM.
FOO2.DNAS.FLOWERS.COM. IN CNAME Foo-bar.CLOSEBY.EDU.
A disadvantage of DNS is that it is difficult to set up and manage. However, the advantages of using DNS for DECnet application services name mappings are that DNS automatically propagates information to all systems that rely on it, and the mapping information is centrally maintained. If you do not already have DNS, and are not on the Internet, you must create a fake root name server before DNS can map DECnet application services node names to IP addresses. Contact Process Software Technical Support for information and assistance in setting up a fake root name server.
A similar configuration can be also be accomplished using host table aliases.
Creating a Name-Mapping Database
To create name-mapping entries that map each six-character DECnet node name to its corresponding TCP/IP node name:
1. Use the ADD NAME-MAPPING command in the NOT-CONFIG utility (MULTINET CONFIGURE /NOT) to add entries for each remote node that needs to communicate with your node.
2. When creating a name mapping, set the DOMAIN-DEFAULT global parameter to the domain with the anticipated greatest number of nodes and use name mapping to describe only the exceptions. For example, the following graphic shows two ways to handle name mapping:
In the Recommended solution, because Site A has the greatest number of nodes, set the DOMAIN-DEFAULT parameter to FNORD.COM at both sites. Using this solution, the exceptions to the network (that is, those nodes at Site B) are the only ones that need to be described in the name-mapping database.
The four host entries in the name-mapping database are:
B1 B1.FLOWERS.COM B3
B3.FLOWERS.COM
B2 B2.FLOWERS.COM B4 B4.FLOWERS.COM
If you specify a node name without a dot, the domain set by DOMAIN-DEFAULT is added to the end of the node name. Therefore, any node name at Site A (A1-A18) maps to node.FNORD.COM automatically.
In the Not recommended solution for Site B, the name-mapping database contains 18 nodes:
A1 A1.FNORD.COM A7
A7.FNORD.COM A13 A13.FNORD.COM
A2 A2.FNORD.COM A8 A8.FNORD.COM A14 A14.FNORD.COM
A3 A3.FNORD.COM A9 A9.FNORD.COM A15 A15.FNORD.COM
A4 A4.FNORD.COM A10 A10.FNORD.COM A16 A16.FNORD.COM
A5 A5.FNORD.COM A11 A11.FNORD.COM A17 A17.FNORD.COM
A6 A6.FNORD.COM A12 A12.FNORD.COM A18 A18.FNORD.COM
Because the local domain at Site B is FLOWERS.COM, nodes B1 through B4 will map to node.FLOWERS.COM automatically.
While the Not recommended method works, it requires more maintenance.
3. Propagate the database to each host running DECnet application services.
Note: It is important that you keep the databases up to date. The more nodes in your network, the more difficult name-mappings are to manage, especially if nodes are managed by different people.