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.)
1. Run the User Environment Test Package (UETP), if it is available, to test DECnet hardware and software on your node and an adjacent node.
Note
To run the UETP on your system, the MIRROR object must have default access to your system (see Section 3.2.2.3).
Log in to the SYSTEST account using the password UETP and enter the following command:
$ @SYS$TEST:UETPReturn
Run "ALL" UETP phases or a "SUBSET" [ALL]? SReturn
You can choose one or more of the following phases: DEVICE, LOAD, DECNET, CLUSTER
Phase(s): DECNETReturn
The DECnet phase performs tests on the following:
a. The local node (the node on which the UETP software is running) b. All circuits in sequence
c. All adjacent nodes, and all circuits in parallel
A test on an adjacent node should normally last no more than 2 minutes. The DECnet node and circuit counters are zeroed at the beginning of the test to permit failure monitoring. The UETP output displays the condition of the circuit to the adjacent node and any response timeouts or errors indicated by the counters. (For a complete description of the UETP procedure, refer to the upgrade and installation procedures manual.)
2. Copy a file to an adjacent DECnet for OpenVMS node (if one is available), copy it back to your node, and compare the two files. Arrange with the system manager of the adjacent node to obtain an account with NETMBX privilege that will permit you to access a directory on that node. Then perform the steps given below. (Refer to Chapter 2 for a description of how to perform file operations over the network.)
a. Create a temporary file for the test. To create the file, copy one of your files and name it TEST1.TMP.
b. Copy your test file to the directory on the remote node.
c. Issue a DIRECTORY command specifying the test file TEST1.TMP in the remote directory, to verify that the file has been copied.
d. Copy the file back to your own node, using the file name TEST2.TMP. e. Issue a DIRECTORY command specifying the name of the file
(TEST2.TMP) in your own directory, to verify that the file has been copied back to your node.
f. Issue a DIFFERENCES command to compare the original file (TEST1.TMP) and the file copied back from the remote node (TEST2.TMP).
g. If the files are the same, delete all test files on both nodes.
The DCL commands in Example 3–4 show how a system manager copies a file (named LOCALFILE.LIS) to TEST1.TMP locally and then copies the TMP file to a remote directory (RNODE::DISK1:[GENERAL]) and back again, comparing the results to verify that the local node is connected to the network. If you use the commands in this example, substitute the name of your own file for the file name LOCALFILE.LIS, and the name of the
remote directory to which you have access in place of the directory name (RNODE::DISK1:[GENERAL]).
Example 3–4 Sample Commands to Verify Connection to Another Node
$ COPY LOCALFILE.LIS TEST1.TMP
$ COPY TEST1.TMP RNODE::DISK1:[GENERAL]* $ DIRECTORY RNODE::DISK1:[GENERAL]TEST1.TMP $ COPY RNODE::DISK1:[GENERAL]TEST1.TMP TEST2.TMP $ DIRECTORY TEST2.TMP
$ DIFFERENCES TEST1.TMP TEST2.TMP $ DELETE TEST1.TMP;*,TEST2.TMP;*
$ DELETE RNODE::DISK1:[GENERAL]TEST1.TMP;*
3. Send mail to and receive mail from another node that supports the Mail utility. To carry out this test, arrange with the system manager of a remote node on your network to have access to an account (with WRITE and DELETE privileges) on that node. Then follow the steps given below. (For a discussion of using MAIL over the network, see Chapter 2.)
a. Using the Mail utility, send a mail message to the account on the remote node.
b. Log in to the account on the remote node using the SET HOST command. c. Read the mail message as received on the remote node, forward it back to the sender, exit from MAIL on the remote node, and log out of the remote system.
d. Check that you have received the mail message on your local 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.
• Software or hardware errors: If you receive DECnet error messages, refer
to the section on common error messages. (See Section 4.3.1.)
You can review the DECnet for OpenVMS installation procedure to ensure that you followed all instructions in installing the software. You can also check the communications hardware to be sure it is set up and connected properly, according to the instructions in the hardware user manuals. To test the hardware, perform controller loopback tests to determine if the communications controller in your processor is working. Also check the controller on the remote node. For a summary description of controller loopback testing, refer to the section on testing the network. (See Chapter 4.) If these tests fail, contact your network manager.
• Transient network problems: If you cannot verify connectivity because
a node is not reachable or the network is slow to respond, try to rerun the tests at a time when you are sure the nodes are available or when computer usage is not at a peak. DECnet messages indicate when a remote node is not reachable.