2.1.1 Remote Loopback Test
The remote loopback test checks the ability to create logical links between the
DECnet host and the Gateway-ST regardless of the physical route taken by the
test data. Start with this test if you are unsure of the location of the problem.
To run the remote loopback test, you must know the Gateway-ST privileged
username and password. At the NCP prompt enter the following command:
NCP> LOOP NODE
gateway-node-name USER username PASSWORD password [...]
For example,
NCP> LOOP NODE GWY USER MARSHALL PASSWORD WILDERNESS COUNT 10
However, in earlier versions of OpenVMS, DECnet NCP might not pass the
supplied access control information to the Gateway-ST; therefore, the LOOP
NODE command fails with the following error message:
%NCP-I-NMLRSP, listener response - mirror connect
failed, access control rejected
To work around this problem, you can establish default outgoing access control
at your DECnet node. Then issue the LOOP NODE command:
NCP> SET NODE
gateway-node-name NONPRIVILEGED USER username-
_PASSWORD
password
NCP> LOOP NODE
gateway-node-name [...]
NCP> CLEAR NODE
gateway-node-name NONPRIVILEGED USER PASSWORD
Note that all connections issued from your DECnet node to the specified
Gateway-ST can potentially use the default access control you have established.
Therefore, be sure to leave the default access control set up for the duration of
the loopback test only.
If this test runs successfully, you can assume it is possible to create logical
links between your local DECnet node and the Gateway-ST. Use the SNANCP
loopback tests to check the link from the Gateway-ST to the IBM network.
If you get an error with this test, run the executor loopback test to further
isolate your problem.
2.1.2 Executor Loopback Test
The executor loopback test checks the DECnet software in the node you are
using; it does so by setting up and sending test data through an internal logical
link. If this test is successful, the local DECnet software is not causing your
problem.
Using Loopback Tests 2–7
