If you are a user with an account on a system that is a node on a DECnet network, you can gain access to the network by logging in to your account on the node, provided you have the privileges required by the network. The minimum privileges required to access the network for general user operations are TMPMBX and NETMBX. To verify that you have these privileges, enter the DCL command SHOW PROCESS/PRIVILEGES. For example, enter the following:

$ SHOW PROCESS/PRIVILEGES

 2-SEP-1992 15:46:38.24   User: WING     Process ID: 2020024E
                          Node: RON      Process name: "WING"

Process privileges:
 TMPMBX         may create temporary mailbox
 NETMBX         may create network device

Process rights:
 INTERACTIVE
 REMOTE

System rights:
 SYS$NODE_RON

If necessary, ask the system manager to provide you with the required privileges.

To log in to the system, follow the standard login procedure (see VSI OpenVMS User's Manual). You can now perform all general user operations on the network, including sending and receiving mail and accessing remote files. Network user operations are described in Chapter 2.

To display the name of your local node, use the DCL command SHOW LOGICAL SYS$NODE. For example, to display the name of the local node ORANGE, enter the following:

$ SHOW LOGICAL SYS$NODE

"SYS$NODE" = "ORANGE::" (LNM$SYSTEM_TABLE)

To learn how your node relates to the rest of the network, you can enter the DCL command SHOW NETWORK. The command display includes the address and name of your local node.

If your node is a routing node, the SHOW NETWORK display lists the other nodes (in your area) to which your node has access and provides routing information about the path to each node. In a multiple-area network, the display also indicates the path to the area router through which your node has access to nodes in other areas. (See Chapter 1 for a discussion of routing over the network.)

The following example is the network display for routing node ORANGE connected to Ethernet circuit SVA-0.

$ SHOW NETWORK

VAX/VMS Network status for local node 2.5 ORANGE on 15-JUN-1992 10:10:10

The next hop to the nearest area router is node 2.2 VIOLET:

             Node         Links  Cost Hops  Next Hop to Node

             2.5 ORANGE     0      0    0   Local →   2.5 ORANGE
             2.2 VIOLET     1      1    1   SVA-0 →   2.2 VIOLET
             2.3 PURPLE     0      1    1   SVA-0 →   2.3 PURPLE
             2.4 YELLOW     0      1    1   SVA-0 →   2.4 YELLOW

If your node is an end node, the SHOW NETWORK display identifies your node by name and address, but does not provide a list of accessible nodes. If your end node is connected to a multiaccess Ethernet circuit, however, the display identifies a particular router designated to perform routing services for the end node. The following example shows the display for end node YELLOW on an Ethernet.

$ SHOW NETWORK

VAX/VMS Network status for local node 2.4 YELLOW on 15-JUN-1992 10:15:00

This is a nonrouting node, and does not have any network information.
The designated router for YELLOW is node 2.5 ORANGE.

If the network is not available at the time you enter the SHOW NETWORK command (for example, if DECnet for OpenVMS is temporarily turned off), the message ‘‘Network unavailable’’ is displayed.

You can obtain additional information about the network by means of the Network Control Program (NCP) utility. The NCP commands you can use to monitor the network are described in Chapter 4.

You can also log in to other nodes on the network from your local system. DECnet for OpenVMS provides a network command terminal facility that permits you to log in to a remote node on which you have an account, and use the facilities of that system while you are physically connected to the local system. (The network command terminal facility is also referred to as the network virtual terminal facility.)

To access a remote node, enter the DCL command SET HOST and specify the remote node name or address. If the network link cannot be established, you will receive an error message. Otherwise, you can log in using the login procedure required by the remote node (which need not be a DECnet for OpenVMS node).

For example, user JONES on node ORANGE can access DECnet for OpenVMS system YELLOW, on which he has an account, as follows:

$ SET HOST YELLOW
USERNAME: JONES
PASSWORD:
            Welcome to VAX/VMS Version V5.5 on node YELLOW
$

If you attempt to gain access to another DECnet for OpenVMS node using invalid access information, the host system responds with the message ‘‘User authorization failure.’’ If you want to try to access the node again, press RETURN and you will again be prompted for a user name and password. After a number of unsuccessful attempts, the link will be disconnected. If you want to abort the login procedure, enter Ctrl/Z at the user name or password prompt (or enter Ctrl/Y twice, as described below).

Once you are logged in to a remote node using the SET HOST command, you can perform any operation on the remote node as though you were logged in to that node locally.

You can terminate the remote session in two ways:

The message ‘‘%REM-S-END, control returned to node _nodename::’’ is displayed and you are returned to the local node.

If DECnet cannot maintain a connection to the remote node, the remote session is terminated, the message ‘‘Path lost to partner’’ may be displayed, and you are returned to the local node. The path may have been lost because the other node (or an intermediate node on the path to that node) went down temporarily, or a transient network error occurred. If the SHOW NETWORK display indicates that the remote node is still reachable, you can try to log in to that node again. (For a discussion of network messages, see Chapter 4.)

A network is a flexible configuration of computers and terminals interconnected by communications lines. Identify the equipment you need to connect your computer to an existing network. For each connection, this equipment normally includes

Consult your sales support representative if you are not familiar with the equipment that you require, or if you need to install such equipment. Following the instructions in the hardware user manuals included with the equipment, you should be able to connect each network communications line to the appropriate port.

A computer can be connected to the network by means of a local area network (LAN) such as Ethernet or FDDI.

VAX: A system can also be connected to a network by means of a synchronous point-to- point line or a low-speed, low-cost asynchronous line. An asynchronous point-to-point connection can be established over any terminal line between a DECnet for OpenVMS system and another system that supports the DCMP, data communications message protocol over asynchronous lines. An asynchronous connection can optionally be made over a dialup line (for example, a telephone line) if a modem is used at each end of the connection. A modem is a device that connects the terminal line to the telephone line.♦

A processor can have a number of communications ports, depending on the model. For example, the VAXstation 3100 illustrated in Figure 3.1 has two asynchronous terminal ports and one Ethernet port.

You can connect this Ethernet port by means of a transceiver cable to an H4000 transceiver that is attached to an Ethernet coaxial cable.

VAX: You can use one of the asynchronous terminal ports as an asynchronous DECnet dialup line.♦

Figure 3.2 illustrates a processor unit with an Ethernet port in the upper right corner to which you can connect a ThinWire Ethernet T–connector. Be sure a ThinWire Ethernet cable connection for the VAXstation 3100 is available in your office and that the ThinWire segment is properly terminated.

As an example of a large VAX system, Figure 3–3 shows a VAX 8800 processor. The system has three network connections:

Before you bring up DECnet for OpenVMS on your system, take the following steps to prepare your system to function as part of the network:

3.2.2.1. Privileges Required for Network Operations

The minimum privileges that a system manager normally requires to configure and control the network and run network programs are SYSPRV, OPER, TMPMBX, NETMBX and BYPASS. Refer to VSI OpenVMS DECnet Networking Manual for more information about the privileges required to perform network operations.

Specify the DCL command SHOW PROCESS/PRIVILEGES to determine which of your authorized privileges are currently enabled. Then specify the command SET PROCESS/PRIVILEGES to enable any additional privileges, for which you are authorized, that are required for network operations.

Before you specify how your node is to be configured as part of an existing network, make the following decisions:

To permit your node to communicate with other nodes on the network, you must have a DECnet for OpenVMS license and you must register the accompanying DECnet for OpenVMS PAK on your system using the OpenVMS License Management utility. You can purchase either an end node license or a full function license for systems that support routing. The end node PAK permits you to configure your node only as an end node.

The full function PAK permits you to configure your node as either a routing node or an end node. You can also use the full function PAK to upgrade from end node to full function capability. Check the DECnet for OpenVMS Software Product Description to determine if routing is supported on your processor.

Refer to the VSI OpenVMS License Management Utility Guide for additional information on licensing.

You can register the DECnet for OpenVMS PAK before or after you configure DECnet for OpenVMS, as described in the following section.

You are now ready to configure your DECnet for OpenVMS system. You can configure the node automatically or manually:

The system manager at each node in the network is responsible for the DECnet for OpenVMS configuration database for the node. The database includes files that describe the local (executor) node and the other nodes in the network with which the local node can communicate, as well as the circuits and lines that connect the local node to the network. The network database also includes information on the logging collection points (such as the logging monitor) to which network events are reported. In addition, DECnet for OpenVMS provides a default object database describing all objects (such as MAIL) known to the network. Each node in the network has such a database.

The configuration database comprises the volatile database (the working copy of the database that reflects current network conditions) and the permanent database (which provides the initial values for the volatile database when you start the network). Modifications to the volatile database exist only while the network is running. Changes made to the permanent database remain after the network is shut down, but do not affect the current system.

As system manager, you provide network component information, from the point of view of the local node, in the configuration database at the local node. Use the Network Control Program (NCP) to supply this information in the form of parameter values, which determine how the various components of the network function together. Use NCP DEFINE commands to establish the contents of the permanent database and SET commands to specify the contents of the volatile database. Use PURGE commands to delete permanent database entries and CLEAR commands to delete or reset volatile database entries.

The two types of asynchronous DECnet connections you can establish are:

The asynchronous connection can be between two routers, a router and an end node, or two end nodes. If you are on an end node and want to make an asynchronous connection, it will be your only connection to the network, because an end node can have only one active circuit.♦

3.3.3.1. Establishing a Static Asynchronous Connection

VAX: On systems that support it, a static asynchronous DECnet connection is a permanent connection between two nodes. This type of connection can be made in one of two ways:

• The nodes can be connected by a physical line (a null modem cable) attached to a terminal port at each system. No modems are required. You can communicate with the other system at any time.

• The connection can be made over a dialup line using modems at both ends of the line. For example, your system can establish a static asynchronous connection to a remote node over a telephone line.

You can configure your static asynchronous line as soon as you have executed NETCONFIG.COM, and then turn on the network manually. If your system is brought up as a routing node, you can establish a static asynchronous connection at any time, no matter how many network connections you already have.

Follow the steps outlined in this section to establish a static asynchronous connection. For the connection to be successful, the node with which you are creating a DECnet link must also establish an asynchronous DECnet connection with your node. (The line speeds at each end of the connection must be the same.)

1. Log in to the SYSTEM account on your node.

2. Load the asynchronous DCMP driver, NODRIVER (NOA0). Enter the following commands at your terminal (or include them in the site-specific startup procedure before you boot the system):

   $ RUN SYS$SYSTEM:SYSGEN
   SYSGEN>  CONNECT NOA0/NOADAPTER
   SYSGEN>  EXIT

   The asynchronous driver must be loaded before any asynchronous connection can be made.

3. To set up the terminal line to become a static asynchronous DECnet line, use the DCL command SET TERMINAL device-name, with the appropriate qualifiers, as shown in the following examples. Device-name represents the name of the terminal port to which the line that you want to make a static asynchronous DECnet line is connected. (All references to a device in this section refer to the terminal port.) If there is more than one terminal attached to your system, you must specify a SET TERMINAL command for each terminal line that will be used for a static asynchronous DECnet connection.

   1. Nondialup line: For a nondialup configuration, enter the following SET TERMINAL command to convert a terminal line to a static asynchronous line:

      $ SET TERMINAL/PERMANENT/PROTOCOL=DDCMP device-name:

      For example, to set up a 2400-baud terminal line connected to port TTA0 on your system to be a static asynchronous DECnet line, enter the following command:

      $ SET TERMINAL/PERMANENT/PROTOCOL=DDCMP TTA0:

   2. Dialup line: For a dialup configuration, enter the following SET TERMINAL command to convert the terminal line to a static asynchronous DECnet line with modem control:

      $ SET TERMINAL/PERMANENT/MODEM/NOAUTOBAUD -
      _$ /NOTYPE_AHEAD/PROTOCOL=DDCMP device-name:

      For example, if the line connected to terminal port TTB0 is connected to a 2400-baud modem, specify this command:

      $ SET TERMINAL/PERMANENT/MODEM/NOAUTOBAUD -
      _$ /NOTYPE_AHEAD/PROTOCOL=DDCMP TTB0:

   You can ensure that these SET TERMINAL commands will be executed automatically each time the network is started in the future by modifying your site-specific startup procedure to include all required SET TERMINAL commands before the command @SYS$MANAGER:STARTNET.

4. After configuring your node, configure the asynchronous lines and circuits in the network database. Use NCP commands to define each asynchronous line and accompanying circuit as being in the ON state. (The line and circuit are turned on when SYS$MANAGER:STARTNET.COM is executed.) Enter the following commands:

   $ RUN SYS$SYSTEM:NCP
   NCP>DEFINE LINE dev-c-u STATE ON RECEIVE BUFFERS 4 -
       _LINE SPEED baud-rate
   NCP>DEFINE CIRCUIT dev-c-u STATE ON
   NCP>EXIT

   Baud-rate is the speed at which the line sends and receives data. For an asynchronous line or circuit, dev-c-u is defined as follows:

   dev	The first two letters of the asynchronous device name (possible values are TT and TX).
   c	A decimal number (0 or a positive integer) designating a device's hardware controller. If the third letter of the device name is A, c equals 0. If the third letter of the device name is B, c equals 1, and so on.
   u	The unit number of the device name; u is always equal to 0 or a positive integer.

   An example is the device identifier TT-0-0, which represents the asynchronous device name TTA0.

   A minimum of four buffers should be allocated for data reception over the line. An insufficient number of receive buffers can result in timeouts and loss of packets (see VSI OpenVMS DECnet Networking Manual).

   For example, to use a line connected to port TTA0 at 2400 baud, run NCP and enter the following commands to define the line and circuit:

   $ RUN SYS$SYSTEM:NCP
   NCP>DEFINE LINE TT-0-0 STATE ON RECEIVE BUFFERS 4 -
       _LINE SPEED 2400
   NCP>DEFINE CIRCUIT TT-0-0 STATE ON
   NCP>EXIT

   If the line speed at the other end of the connection is changed after the initial static asynchronous connection is made, you can use the DEFINE LINE command to change the line speed for your end of the connection to match the line speed at the other end. The line speed will be changed the next time the line is turned on.

5. For security over a dialup connection, you can run NCP and establish optional transmit and receive passwords for the local end of the static asynchronous dialup link. The transmit password is the password sent to the other node during connection startup; the receive password is the password expected from the other node during connection startup. You must also use NCP to specify that your asynchronous circuit is to verify the password supplied by the other node. If the correct passwords are not supplied, the asynchronous connection cannot be made.

   Although transmit and receive passwords are not mandatory for static asynchronous dialup links, they add to the security of your DECnet connection. Passwords can contain from one to eight alphanumeric characters and must be delimited with quotation marks if they contain spaces. Specify the following commands:

   $ RUN SYS$SYSTEM:NCP
   NCP>DEFINE CIRCUIT dev-c-u VERIFICATION ENABLED
   NCP>DEFINE NODE node-id TRANSMIT PASSWORD transmit-password -
       _RECEIVE PASSWORD receive-password
   NCP>EXIT

   Node-id is the name of the remote node to which your node will be connected.

   In the following example, the name of your local node is LOCALA, the name of the remote node is REMOTB, your asynchronous circuit is TT-0-0, the transmit password is PASSA, and the receive password is PASSB. Enter the following on node LOCALA:

   $ RUN SYS$SYSTEM:NCP
   NCP>DEFINE CIRCUIT TT-0-0 VERIFICATION ENABLED
   NCP>DEFINE NODE REMOTB TRANSMIT PASSWORD PASSA -
       _RECEIVE PASSWORD PASSB
   NCP>EXIT

   If you have defined passwords for the local end of the link, you must notify the remote node system manager to establish transmit and receive passwords for the remote end of the static asynchronous DECnet dialup link. For the previous example, the remote system manager should enter these commands:

   $ RUN SYS$SYSTEM:NCP
   NCP>DEFINE CIRCUIT TT-1-0 VERIFICATION ENABLED
   NCP>DEFINE NODE LOCALA TRANSMIT PASSWORD PASSB -
       _RECEIVE PASSWORD PASSA
   NCP>EXIT

6. If the network is not already on, turn on the network at your node by entering the following command:

   $ @SYS$MANAGER:STARTNET

   This command starts the network and causes the permanent database entries defined above to be entered in the volatile database on the running network. If the network was already running before you began the static asynchronous connection procedure, enter the following commands to cause the permanent database entries to be entered in the volatile database.

   $ RUN SYS$SYSTEM:NCP
   NCP>SET LINE dev-c-u ALL
   NCP>SET CIRCUIT dev-c-u ALL
   NCP>SET NODE node-id ALL
   NCP>EXIT

   If the line and circuit could not be set to ON in the volatile database, causing DECnet to fail to gain control of the line, the following error message appears:

   % NCP-I-NMLRSP, LISTENER RESPONSE - Operation failure

   If the static asynchronous connection cannot be made, refer to the section on asynchronous connection problems. (See Chapter 4.)

7. If you want to turn off the asynchronous lines temporarily, run NCP and enter the following commands:

   $ RUN SYS$SYSTEM:NCP
   NCP>SET LINE dev-c-u STATE OFF
   NCP>SET CIRCUIT dev-c-u STATE OFF
   NCP>CLEAR LINE dev-c-u ALL
   NCP>CLEAR CIRCUIT dev-c-u ALL
   NCP>EXIT

   To turn the static asynchronous DECnet line back on, enter the following NCP commands:

   $ RUN SYS$SYSTEM:NCP
   NCP>SET LINE dev-c-u ALL
   NCP>SET CIRCUIT dev-c-u ALL
   NCP>EXIT

8. If you want to switch an asynchronous DECnet line back to a terminal line with DECnet running, you must clear the line and circuit entries from the network volatile database. To clear the entries, enter these commands:

   $ RUN SYS$SYSTEM:NCP
   NCP>SET LINE dev-c-u STATE OFF
   NCP>SET CIRCUIT dev-c-u STATE OFF
   NCP>CLEAR LINE dev-c-u ALL
   NCP>CLEAR CIRCUIT dev-c-u ALL
   NCP>EXIT

   To switch the line for which modem control was not enabled back to a terminal line, use this command:

   $ SET TERMINAL/PERMANENT/PROTOCOL=NONE device-name:

   For example, to switch the nondialup line connected to port TTA0 back to a terminal line, enter the command:

   $ SET TERMINAL/PERMANENT/PROTOCOL=NONE TTA0:

   To switch the line for which modem control was enabled back to a terminal line, use this command:

   $ SET TERMINAL/PERMANENT/MODEM/AUTOBAUD -
   _$ /TYPE_AHEAD/PROTOCOL=NONE device-name:

   For example, to switch the dialup line connected to port TTB0 back to a terminal line, enter the command:

   $ SET TERMINAL/PERMANENT/MODEM/AUTOBAUD -
   _$ /TYPE_AHEAD/PROTOCOL=NONE TTB0:

Example 3.2 lists the commands that the system managers of two nodes must put into the permanent databases to cause a static asynchronous connection to be established over the dialup line shown in Figure 3–4 when the network is turned on at each node.

Commands issued at the local node (LOCALA):

$ RUN SYS$SYSTEM:SYSGEN
SYSGEN> CONNECT NOA0/NOADAPTER
SYSGEN> EXIT
$ SET TERMINAL/PERMANENT/MODEM/DIALUP/NOAUTOBAUD/NOTYPE_AHEAD -
_$ /PROTOCOL=DDCMP TTA0:
$ RUN SYS$SYSTEM:NCP
NCP>DEFINE LINE TT-0-0 STATE ON RECEIVE BUFFERS 4 LINE SPEED 2400
NCP>DEFINE CIRCUIT TT-0-0 STATE ON VERIFICATION ENABLED
NCP>DEFINE NODE REMOTB TRANSMIT PASSWORD PASSB RECEIVE PASSWORD PASSA
NCP>EXIT

Commands issued at the remote node (REMOTB):

$ RUN SYS$SYSTEM:SYSGEN
SYSGEN> CONNECT NOA0/NOADAPTER
SYSGEN> EXIT
$ SET TERMINAL/PERMANENT/MODEM/NOAUTOBAUD/NOTYPE_AHEAD -
_$ /PROTOCOL=DDCMP TTB0:
$ RUN SYS$SYSTEM:NCP
NCP>DEFINE LINE TT-1-0 STATE ON RECEIVE BUFFERS 4 LINE SPEED 2400
NCP>DEFINE CIRCUIT TT-1-0 STATE ON VERIFICATION ENABLED
NCP>DEFINE NODE LOCALA TRANSMIT PASSWORD PASSA RECEIVE PASSWORD PASSB
NCP>EXIT

Note that if an asynchronous connection is made to a system that does not support DECnet for OpenVMS, the commands issued at the remote node must be appropriate for that system.♦

3.3.3.2. Establishing a Dynamic Asynchronous Connection

VAX: A dynamic asynchronous DECnet connection is a temporary connection between two nodes, normally over a telephone line through the use of modems. The line at each end of the connection can be switched from a terminal line to a dynamic asynchronous DECnet line. Configuration of dynamic asynchronous lines is performed automatically by DECnet when DECnet establishes a dynamic connection. A dynamic asynchronous connection is normally maintained only for the duration of a telephone call.

Note

A dynamic asynchronous connection to a node can be initiated from any node with lines that support the DECnet asynchronous DCMP protocol.

On a DECnet for OpenVMS node, you have the option of performing the initial steps of the dynamic asynchronous connection process (steps 1 and 2 below) before you turn on the network at your node (step 3). The later steps of the process (starting with step 4) must occur when the line is being switched to DECnet.

Use the steps outlined in the following list to establish a dynamic asynchronous DECnet connection. This procedure assumes the local node is originating the connection and switching the terminal line on for DECnet use. The connection must be to a DECnet for OpenVMS node on which you have an account with NETMBX privilege. The steps that the system manager at the remote node must perform in order for the dynamic asynchronous DECnet link to be established successfully are also indicated in the list.

1. Log in to the system management account and enter the following commands interactively (or include them in the site-specific startup procedure before you boot the system). These commands load the asynchronous driver NODRIVER (NOA0) and install DYNSWITCH software on your system.

   $ RUN SYS$SYSTEM:SYSGEN
   SYSGEN> CONNECT NOA0/NOADAPTER
   SYSGEN> EXIT
   $ INSTALL:=$SYS$SYSTEM:INSTALL
   $ INSTALL/COMMAND
   INSTALL> CREATE SYS$LIBRARY:DYNSWITCH/SHARE -
   _ /PROTECT/HEADER/OPEN
   INSTALL> EXIT

   The system manager of the remote node must also enter these commands.

   Additionally, the system manager at the remote node must enter the commands given below. These commands enable the use of virtual terminals for the terminal line that is to be switched, and set the DISCONNECT characteristic for the terminal line. The virtual terminal capability permits the process to continue running if the physical terminal you are using becomes disconnected.

   $ RUN SYS$SYSTEM:SYSGEN
   SYSGEN> CONNECT VTA0/NOADAPTER/DRIVER=TTDRIVER
   SYSGEN> EXIT
   $ SET TERMINAL/EIGHT_BIT/PERMANENT/MODEM/DIALUP -
   _$ /DISCONNECT device-name:

   Device-name is the name of the terminal port to which the dynamic asynchronous connection is made.

2. You must establish the required transmit password at the originating end of the dynamic asynchronous dialup link. The transmit password is the password sent to the remote node during connection startup. Use NCP to enter a command to define the transmit password for the remote node. The password can contain one to eight alphanumeric characters and should not contain any spaces. Specify the following commands:

   $ RUN SYS$SYSTEM:NCP
   NCP>DEFINE NODE node-id TRANSMIT PASSWORD password
   NCP>EXIT

   Node-id is the name of the remote node with which your node is forming a connection.

   In the following example, the node name of your local node is LOCALA, the transmit password is PASSA, and the remote node with which you are creating a dynamic asynchronous dialup link is REMOTC.

   $ RUN SYS$SYSTEM:NCP
   NCP>DEFINE NODE REMOTC TRANSMIT PASSWORD PASSA
   NCP>EXIT

   For each remote node with which you will create a dynamic asynchronous DECnet dialup link, you must define a transmit password in a separate command.

   The system manager for the node at the other end of the connection must define that same password as a receive password for your node (the password expected to be received from your node). The remote system manager should also specify the parameter INBOUND ROUTER or INBOUND ENDNODE, to indicate the type of node (router or end node) that is expected to initiate the dynamic connection. These are the commands the remote manager should enter:

   $ RUN SYS$SYSTEM:NCP
   NCP>DEFINE NODE node-id -
   _ RECEIVE PASSWORD password INBOUND node-type
   NCP>EXIT

   For example, if your node LOCALA is an end node and your transmit password is PASSA, the manager at REMOTC should issue the following command:

   $ RUN SYS$SYSTEM:NCP
   NCP>DEFINE NODE LOCALA RECEIVE PASSWORD PASSA INBOUND ENDNODE
   NCP>EXIT

3. DECnet must be running on both nodes for the remaining steps. If you have not already done so, turn on the network by entering the following command (and request that the remote system manager do so also):

   $ @SYS$MANAGER:STARTNET
   

   If the network was already running before you began the dynamic asynchronous connection procedure, enter these commands to cause the permanent database entry to be entered in the volatile database:

   $ RUN SYS$SYSTEM:NCP
   NCP>SET NODE node-id ALL
   NCP>EXIT

4. The remaining steps can be performed by any user with NETMBX privilege. Log in to your local system and enter the following DCL command on your terminal to cause your process to function as a terminal emulator (which makes the remote terminal appear to be a local terminal connection):

   $ SET HOST/DTE device-name:

   Device-name is the name of your local terminal port that is connected to the modem. If both systems use modems with autodial capabilities (for example, DF03, DF112 or DF224 modems that support an autodial protocol), you can optionally include the /DIAL qualifier on the SET HOST/DTE command to cause automatic dialing of the modem on the remote node, as follows:

   $ SET HOST/DTE/DIAL=number device-name:

5. If you are not using automatic dialing, dial in to the remote node manually.

6. Once the dialup connection is made and you receive the remote system welcome message, log in to your account on the remote node.

7. While logged in to your account on the remote node, enter the following command to cause the line to be switched to a DECnet line automatically:

   $ SET TERMINAL/PROTOCOL=DDCMP/SWITCH=DECNET

   The following message indicates that the DECnet link is being established:

   %REM-S-END - control returned to local-nodename::
   $

   To check whether the communications link has come up, specify the following command on the local system:

   $ RUN SYS$SYSTEM:NCP
   NCP>SHOW KNOWN CIRCUITS
   NCP>EXIT

   The resulting display should list a circuit identified by the mnemonic TT or TX, depending on the asynchronous device, and indicate that it is in the ON state.

   When the DCL prompt ($, by default) appears on your terminal screen, you can begin to communicate with the remote node over the asynchronous DECnet connection.

   If the dynamic connection is not made successfully, refer to the section on asynchronous connection problems. (See Chapter 4.)

8. As an alternative to switching the terminal line to a DECnet line automatically (as described in the previous step), you can switch the line manually. If you originate a dynamic connection to a DECnet for OpenVMS node from a system that does not support DECnet for OpenVMS, manual switching is required; from a DECnet for OpenVMS system, it is optional. If you are originating the connection from a node that does not support DECnet for OpenVMS, follow system-specific procedures to log in to the remote DECnet for OpenVMS node by means of terminal emulation.

   Once you are logged in to the remote node, two steps are required to perform manual switching:

   1. Using your account on the remote DECnet for OpenVMS node, specify the SET TERMINAL command described in step 7, but add the /MANUAL qualifier:

      $ SET TERMINAL/PROTOCOL=DDCMP/SWITCH=DECNET/MANUAL

      You will receive the following message from the remote node indicating the remote system is switching its line to DECnet use:

      %SET-I-SWINPRG The line you are currently logged over is becoming
                                 a DECnet line

   2. Exit from the terminal emulator and switch your line manually to a DECnet line. The procedure depends on the specific operating system on which you are logged in.

      MS–DOS procedure: The following procedure illustrates how an MS–DOS system user on a personal computer, who is originating a dynamic connection to a DECnet for OpenVMS system, exits from the terminal emulator and turns on the DECnet line.

      • Exit from the terminal emulator by pressing CONTROL/F10 (the control key and function key 10).

      • When an MS–DOS prompt (C>) is displayed on the screen, enter the following commands to turn on the line to DECnet and verify that the line is up:

        C> NCP SET LINE STATE ON
        C> NCP READ LOGGING

        After a short interval, a display should appear, showing that the line state is on and the adjacency is up, indicating that DECnet is started at the MS–DOS node.

      DECnet for OpenVMS procedure: The following example shows how a DECnet for OpenVMS user originating a dynamic connection would perform this procedure.

      • Exit from the terminal emulator by pressing the backslash ( \ ) key and the Ctrl key simultaneously on your system.

      • Enter the following command to switch your terminal line to a DECnet line manually:

        $ SET TERMINAL/PROTOCOL=DDCMP TTA0:

        TTA0 is the name of the terminal port on the local node.

      • Enter NCP commands to turn on the line and circuit connected to your terminal port TTA0 manually, as in the following example:

        $ RUN SYS$SYSTEM:NCP
        NCP>SET LINE TT-0-0 RECEIVE BUFFERS 4 -
        _ LINE SPEED 2400 STATE ON
        NCP>EXIT

        Asynchronous DECnet is then started on the local node.

9. You can terminate the dynamic asynchronous link in one of two ways:

   1. Break the telephone connection.

   2. Run NCP and turn off either the asynchronous line or circuit. The two commands you can use are as follows:

      $ RUN SYS$SYSTEM:NCP
      NCP>SET LINE dev-c-u STATE OFF
      NCP>SET CIRCUIT dev-c-u STATE OFF
      NCP>EXIT

      If either of the above NCP commands is entered at the remote node, the line returns to terminal mode immediately. If the command is entered at the local (originating) node, the remote line and circuit remain on for approximately four minutes and then the line returns to terminal mode.

An illustration of the establishment of a dynamic asynchronous connection is shown in Figure 3.5. The commands that must be entered at each end of the connection are shown in Example 3.3.

Commands issued at both the local node (LOCALA) and the remote node
(REMOTC):

$ RUN SYS$SYSTEM:SYSGEN
SYSGEN> CONNECT NOA0/NOADAPTER
SYSGEN> EXIT
$ INSTALL:=$SYS$SYSTEM:INSTALL
$ INSTALL/COMMAND
INSTALL> CREATE SYS$LIBRARY:DYNSWITCH/SHARE/PROTECT/HEADER/OPEN
INSTALL> EXIT

Commands issued at the remote node (REMOTC):

$ RUN SYS$SYSTEM:SYSGEN
SYSGEN> CONNECT VTA0/NOADAPTER/DRIVER=TTDRIVER
SYSGEN> EXIT
$ SET TERMINAL/EIGHT_BIT/PERMANENT/MODEM/DIALUP/DISCONNECT TTB0:
$ RUN SYS$SYSTEM:NCP
NCP>DEFINE NODE LOCALA RECEIVE PASSWORD PASSA INBOUND ENDNODE
NCP>SET NODE LOCALA ALL
NCP>EXIT

Commands issued at the local node (LOCALA):

$ RUN SYS$SYSTEM:NCP
NCP>DEFINE NODE REMOTC TRANSMIT PASSWORD PASSA
NCP>SET NODE REMOTC ALL
NCP>EXIT
$ SET HOST/DTE/DIAL=8556543 TTA0:

! After dialing in automatically to REMOTC, log in to your account on REMOTC.

$ SET TERMINAL/PROTOCOL=DDCMP/SWITCH=DECNET
%REM-S-END - control returned to LOCALA:
$♦

To verify your connection to the network, you can optionally perform the following tests. These tests demonstrate whether your node can communicate with an adjacent node, that is, a node connected to your node by a single physical line. (Your node can reach an adjacent node directly, without data having to be routed through an intermediate node.)

If these tests are successful and you do not receive an error message from DECnet, you have verified that DECnet for OpenVMS is installed correctly. If you are not able to carry out the verification tests successfully, the problem may be software or hardware errors, or possibly transient network problems, as described below.

The network shuts down automatically as part of the normal system shutdown procedure. If your system is running, you can shut down the network at your local node without destroying any active logical links by entering the following commands:

$ RUN SYS$SYSTEM:NCP
NCP>SET EXECUTOR STATE SHUT
NCP>EXIT

When this command sequence is issued, no new links are allowed; when all existing links are disconnected, the network is turned off.

While your system is running, you can stop the network at your node by entering the following commands:

$ RUN SYS$SYSTEM:NCP
NCP>SET EXECUTOR STATE OFF
NCP>EXIT

All logical links are terminated immediately and the network is stopped.

To turn the network on manually, specify the following:

$ @SYS$MANAGER:STARTNET

To start the network if it is not currently active, you must be logged in to the SYSTEM account or have the privileges listed at the beginning of the STARTNET.COM command procedure.

To cause the network to be started each time the operating system is booted, enable the following command in the site-specific startup procedure:

$ @SYS$MANAGER:STARTNET

The system manager is responsible for configuring the node for network operation by supplying information in the DECnet for OpenVMS configuration database about the following network components:

The configuration database is actually two databases: a permanent database that establishes the default parameter values for node startup, and a volatile database that contains the current parameter values.

You can use the Network Control Program (NCP) utility to build the network configuration database manually or to modify its contents. If you are configuring the node for the first time, you can use the automatic configuration command procedure, NETCONFIG.COM, to establish parameters needed to get DECnet running. The procedure for using NETCONFIG.COM is described in an earlier section. (See Section 3.3.2.2.)

When you run NCP and enter a command, NCP will prompt you for selected parameters if you do not supply them. NCP also provides a HELP facility with information about each command, which you can access as follows:

$ RUN SYS$SYSTEM:NCP
NCP>HELP [topic...]

Refer to the VSI OpenVMS DECnet Network Management Utilities for a complete description of the NCP command language.

Use NCP SET commands to establish the contents of the volatile database, and DEFINE commands to establish the contents of the permanent database. You must have OPER privilege to change the volatile database and SYSPRV privilege to change the permanent database.

The permanent database information is supplied to the volatile database when the network is started (that is, the STARTNET.COM command procedure is executed). You can also use the ALL parameter with the SET command to cause all permanent database entries for a network component to be loaded into the volatile database.

The basic NCP commands required to define the network components in the permanent configuration database are shown in the following list. Some of these commands must be used multiple times, such as DEFINE EXECUTOR to define several parameters and DEFINE NODE to list all the nodes in the network.

$ RUN SYS$SYSTEM:NCP
NCP>DEFINE EXECUTOR executor-parameter [...]
NCP>DEFINE NODE node-id
NCP>DEFINE CIRCUIT circuit-id
NCP>DEFINE LINE line-id
NCP>DEFINE OBJECT object-name
NCP>DEFINE LOGGING MONITOR STATE ON
NCP>DEFINE LOGGING MONITOR EVENTS event-list
NCP>EXIT

In an NCP command, node-id can be a node name a maximum of six alphanumeric characters long, or a node address in the form area-number.node-number, where the area number can be from 1 to 63 and the node number can be from 1 to 1023. If no area number is specified, the area number of the executor node is used. The default area number for the executor is 1. The object-name can be up to 16 characters long.

The circuit-id and line-id values are in the form dev-c[-u], defined as follows:

Reference DECnet for OpenVMS Network Management Utilities for a list of device names.

For example, the circuit and line identification for an Ethernet SVA device is in the form SVA-c (such as SVA-0); an example for a QNA device is QNA-0. An example of a synchronous DCMP device identifier is DSV-2, and an example of an asynchronous device identifier is TT-1-0.

NCP commands also recognize the plural forms of the network component names: KNOWN NODES, KNOWN CIRCUITS, KNOWN LINES, KNOWN OBJECTS.

To modify the current configuration of your node, you can issue SET commands for any network component. For example, to add circuit and line entries for the Ethernet UNA device (the DEUNA), specify the following commands:

$ RUN SYS$SYSTEM:NCP
NCP>SET LINE UNA-0 STATE ON
NCP>SET CIRCUIT UNA-0 STATE ON
NCP>EXIT

To determine the contents of your network configuration database, use the NCP commands LIST and SHOW. The LIST command displays information in the permanent database; the SHOW command displays volatile database entries. (For more information on monitoring the network using the network databases, see Chapter 4.) To delete entries from the configuration database, use the PURGE and CLEAR commands. The PURGE command deletes permanent database entries; the CLEAR command deletes or resets volatile database entries.

For example, to list the permanent name and address of a node, enter the following commands:

$ RUN SYS$SYSTEM:NCP
NCP>LIST NODE node-id
NCP>EXIT

To delete a node from the permanent database, enter the following commands:

$ RUN SYS$SYSTEM:NCP
NCP>PURGE NODE node-id ALL
NCP>EXIT

Node-id can be either the node name or the node address. You can also delete an individual parameter for a node. For example, to purge the RECEIVE PASSWORD parameter for node PURPLE, enter the following commands:

$ RUN SYS$SYSTEM:NCP
NCP>PURGE NODE PURPLE RECEIVE PASSWORD
NCP>EXIT

Because the PURGE command does not affect the volatile (memory-resident) copy of the DECnet database, you can access a node deleted with the PURGE command until DECnet is started again. If you use the CLEAR command to delete a node entry, the node entry will reappear in the volatile database after DECnet is started again.

Some of the security measures that you can use to protect your files and system in a network environment are summarized in this section.

As manager of a node, you can protect your system against unauthorized access by users on other nodes in the network by setting passwords for any accounts that you may create. Otherwise, users on other nodes could gain full access to your system by using the SET HOST command to log in to one of the accounts on your node. (Logging in to a node using the SET HOST command is described in Section 3.1.2.)

node"username password"::device:[directory]filename.type;version

$ COPY BOSTON"SMITH ABCDEF"::WORK1:[SMITH]TEST.DAT *

$ COPY BOSTON::WORK1:[SMITH]TEST.DAT *

$ SET DEFAULT SYS$SYSTEM
$ RUN AUTHORIZE
UAF> CREATE/PROXY
UAF> ADD/PROXY MIAMI::MARTIN ALLEN/DEFAULT
UAF> EXIT

$ RUN SYS$SYSTEM:NCP
NCP>SET OBJECT object-name PROXY OUTGOING
NCP>EXIT

$ RUN SYS$SYSTEM:NCP
NCP>SET EXECUTOR INCOMING PROXY DISABLED
NCP>SET OBJECT object-name PROXY INCOMING
NCP>EXIT

$ SET DEFAULT SYS$SYSTEM
$ RUN AUTHORIZE
UAF>ADD NETNONPRIV/PASSWORD=DLB9191A/DEVICE=device-name: -
_ /DIRECTORY=[NETUSER]/UIC=[376,376] -
_ /PRIVILEGE=(TMPMBX,NETMBX)/FLAGS=(RESTRICTED,NODISUSER) -
_ /NOBATCH/NOINTERACTIVE/LGICMD=NL:
UAF>EXIT

$ CREATE/DIRECTORY device-name:[NETUSER]/OWNER_UIC=[376,376]

You can use the NCP commands SHOW and LIST to monitor network activity by displaying the following:

You do not need any privileges to issue SHOW commands, but you need the privilege SYSPRV to issue LIST commands.

Use the SHOW command to monitor the operation of the running network. You can display the characteristics and current status of network circuits, lines and nodes, including the local (executor) node. This information is useful in detecting any changes in the network configuration or operation. For example, if a circuit failure causes some nodes to become unreachable, you can use SHOW commands to check the status of the circuit and the nodes.

In general, the SHOW and LIST commands permit you to indicate what type of information you want NCP to display about the particular component you specify. The display types include the following:

When you display information about network components, you can specify either the singular or plural form of the component in the NCP command. Plural forms of component names are KNOWN (all components available to the local node), ACTIVE (all circuits, lines and logging not in the OFF state), and ADJACENT (all nodes directly connected to the local node).

Typical examples of NCP display commands follow:

$ RUN SYS$SYSTEM:NCP
NCP>SHOW EXECUTOR CHARACTERISTICS
NCP>SHOW KNOWN LINES STATUS
NCP>SHOW ACTIVE CIRCUITS
NCP>SHOW ADJACENT NODES STATUS
NCP>LIST KNOWN NODES
NCP>EXIT

Using the NCP SHOW and LIST commands, you can direct the information displayed to a specified output file. For example:

$ RUN SYS$SYSTEM:NCP
NCP>SHOW KNOWN NODES TO NODES.DAT
NCP>EXIT

This command creates the file NODES.DAT that contains summary information on all nodes known to the local system. If the specified output file exists, NCP appends the display information to that file. The default file type is LIS and the default output file is SYS$OUTPUT.

You can display information about network components on remote nodes using the TELL prefix in the NCP command. The format of the command is TELL node-id SHOW component. For example, to look at remote node counters, specify the following command sequence:

$ RUN SYS$SYSTEM:NCP
NCP>TELL node-id SHOW EXECUTOR COUNTERS
NCP>EXIT

You can use NCP commands to display error and performance statistics about network components at any time while the network is running. DECnet software uses counters to collect statistics for the executor node, remote nodes, circuits and lines automatically. To display the contents of counters, use NCP SHOW COUNTER commands, as in the following typical examples of the commands:

$ RUN SYS$SYSTEM:NCP
NCP>SHOW EXECUTOR COUNTERS
NCP>SHOW NODE TRNTO COUNTERS
NCP>SHOW KNOWN CIRCUITS COUNTERS
NCP>SHOW KNOWN LINES COUNTERS
NCP>SHOW LINE SVA-0 COUNTERS
NCP>EXIT

For the local node and remote nodes, counter statistics cover such subjects as connection requests, user data traffic, timeouts, and errors. Circuit counters cover such topics as the transmission of data packets over the circuit, timeouts, and errors. Line counters cover such information as the transmission of bytes and data blocks over the line and relevant errors. For a complete summary description of all network counters, including the probable causes of particular types of occurrences, refer to the DECnet for OpenVMS Network Management Utilities.

Use NCP commands to control counter usage. You may want to reset counters to zero if you are establishing a controlled environment for test purposes. To reset counters to zero, use the NCP command ZERO COUNTERS (the ZERO command requires the OPER privilege). You can zero counters for the executor node and individual nodes, circuits and lines, or all nodes, circuits and lines, as shown:

$ RUN SYS$SYSTEM:NCP
NCP>ZERO EXECUTOR COUNTERS
NCP>ZERO NODE TRNTO
NCP>ZERO KNOWN CIRCUITS
NCP>ZERO LINE SVA-0 COUNTERS
NCP>EXIT

You can regulate the frequency with which specific counters are logged by issuing the following command sequence:

$ RUN SYS$SYSTEM:NCP
NCP>SET component COUNTER TIMER nn
NCP>EXIT

The variable nn is in seconds. Expiration of the counter timer causes the contents of the counter to be logged and the counter reset to zero. For example, use the following commands to cause a node counter logging event to occur every 600 seconds for the local node:

$ RUN SYS$SYSTEM:NCP
NCP>SET EXECUTOR COUNTER TIMER 600
NCP>EXIT

Use the DECnet event logging facility to monitor significant network events, such as circuit failures or lost packets, on a continuous basis. Whenever a network error or other meaningful event occurs, the DECnet event logger will log an event message to a terminal or file that you specify. Examples of network events that are logged as they happen include the following:

Collection and analysis of network events can provide insight into why a particular error condition exists or why network performance may vary.

As events are detected, the event logger sends them to a collection point for analysis. Collection points are called logging sinks; they can be located on the local node or at a remote node. Event data can go to one or more sinks. Each of the following types of event sinks handles event data in a slightly different way:

In order for logging to occur at your node, logging must be enabled and the events to be logged must be identified. If you use the automatic configuration command procedure, NETCONFIG.COM, logging will be established automatically.

Otherwise, you can use the NCP command SET or DEFINE LOGGING to set the logging sink state to be ON. To identify a remote location for a logging sink, specify the SINK node-id parameter in the command. Use one or more separate commands to define the events to be logged. For example, issue the following commands to cause all network events to be logged to OPCOM and displayed at your network operator terminal:

$ RUN SYS$SYSTEM:NCP
NCP>SET LOGGING MONITOR STATE ON
NCP>SET LOGGING MONITOR KNOWN EVENTS
NCP>EXIT

Alternatively, for each event class, you can specify the specific events to be logged, as follows:

$ RUN SYS$SYSTEM:NCP
NCP>SET KNOWN LOGGING EVENTS event-list
NCP>EXIT

Events in the event list are identified by class and type (in the form class.type). An event class refers to the DECnet software functional layer in which the event occurred. (DECnet layers are described in Chapter 1 and summarized in Section 4.3.2.1.) Event classes logged by DECnet include those listed in Table 4.1. The event type is a decimal number representing a unique event within the class. You can use the asterisk ( * ) wildcard character for event types, and you can specify a single event type or a range of types.

An example of the command to specify event types 5 through 7 in event class 4 is as follows:

$ RUN SYS$SYSTEM:NCP
NCP>DEFINE LOGGING MONITOR EVENTS 4.5-7
NCP>EXIT

Additional examples of commands to define logging events are included in the NETCONFIG.COM example shown in Example 3.1. A complete description of network events, including explanations of probable causes of particular events, is given in the VSI OpenVMS DECnet Network Management Utilities.

The event message displayed by OPCOM is in the following form:

EVENT TYPE class.type, event-text
From node-address (node name) Occurred (date and time)
component type and identifier
descriptive text

An example of a network event message display on the operator terminal at node RED is as follows:

%%%%%%%%%%% OPCOM 15-JUN-1992 11:36:48.83 %%%%%%%%%%%
Message from user DECNET
DECnet event 4.14, node reachability change
From node 2.5 (RED), 15-JUN-1992 11:10:05.16
Node 2.4 (YELLOW), Reachable

Use the SHOW LOGGING command to show what logging is being performed. For example, to display complete information on all logging being conducted at all nodes, use these commands:

$ RUN SYS$SYSTEM:NCP
NCP>SHOW ACTIVE LOGGING KNOWN SINKS
NCP>EXIT

To stop monitoring at the network operator terminal, issue the following commands:

$ RUN SYS$SYSTEM:NCP
NCP>SET LOGGING MONITOR STATE OFF
NCP>CLEAR LOGGING MONITOR ALL
NCP>EXIT

To turn monitoring back on, issue these commands:

$ RUN SYS$SYSTEM:NCP
NCP>SET LOGGING MONITOR STATE ON
NCP>EXIT

To permanently disable logging at the network operator terminal, enter the following commands:

$ RUN SYS$SYSTEM:NCP
NCP>PURGE LOGGING MONITOR ALL
NCP>EXIT

Additional tools are available to determine network activity or exercise network operations. The following is a brief list of some of these tools:

Node-level loopback tests determine whether the DECnet for OpenVMS software can form logical links and exchange data with a DECnet process on a remote node or on the local node. If no error messages are generated, the test is successful. If a test fails, you can perform the next test in sequence to help isolate the cause of the failure.

If the node-level tests are successful, return the line and circuit to the working state (as described at the end of the next section). Otherwise, continue with the circuit-level tests.

If you are unable to perform a loopback test at the node level, perform circuitlevel tests to determine whether the circuit is functioning properly. These tests loop test data through a remote node or through a hardware loopback device on the circuit (called a controller loopback device), depending on the test. (You cannot perform circuit-level loopback tests on asynchronous circuits or lines.)

When using DECnet for OpenVMS, you may receive network-related messages indicating software or hardware problems, transient conditions, or errors in your input. The following lists some common network-related messages, explains what condition may be causing each message, and suggests actions you can take. (All messages displayed on a system, including those generated by DECnet for OpenVMS, are described in the OpenVMS system messages documentation.)

Problems in maintaining the proper functioning of the running network can be difficult to resolve. This section describes the technique for isolating a problem to a particular DECnet software functional layer or layers, and provides troubleshooting suggestions to determine the specific network problem. As system manager of the local node, work with the network manager (if one is available for your network) to resolve these problems. (Refer to the VSI OpenVMS DECnet Networking Manual for information on maintaining a DECnet for OpenVMS node.)

4.3.2.1. Troubleshooting Techniques Based On NA Layers

Techniques for troubleshooting DECnet for OpenVMS problems are based on the layered network design of DECnet Phase IV as specified in the Network Architecture (NA). The NA layers are illustrated in Figure 4.1. Each layer performs particular services as part of the overall network capability provided at the node. (For more information on DECnet for OpenVMS software design, see Chapter 1.)

During troubleshooting, it is useful to distinguish among the network layers in localizing the cause of a particular problem. For example, some problems are characteristic of the Data Link layer, while others are related to the Routing or the End Communications layer (which provides logical link services).

VAX: On systems that support asynchronous connections, attempts to establish asynchronous DECnet connections with other nodes can fail for a variety of reasons. This section describes some reasons for failing to make a static or dynamic connection.♦