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.