HP 3000 Manuals HP 3000 Manuals
Verifying Network Connections and Services
Several line verification tests are available to help you verify the
operation of NS3000/iX services and link products.
NSLOGON establishes temporary connections to other nodes to verify that
the network transport is operating correctly between the two nodes using
the connection.
XPVAL is an interactive test that uses the NetIPC intrinsics to make sure
that the network transport is working correctly.
QVALNS and NSTEST both perform a quick validation of the Network
Services. QVALNS runs through a job while NSTEST runs interactively.
You can run all of these tests either standalone or through the NETTOOL
utility. Hewlett-Packard suggests that you run them through the NETTOOL
utility to take advantage of its facilities, including online help.
To Check the Network Transport
Follow the steps below to use XPVAL to check the network transport.
(Note that you may also use NSLOGON to establish a temporary connection
between nodes to check the network services. See chapter 6 for more
information.)
1. Make sure the network transport is active on this node and on any
other node that will be a part of this test.
2. Run the NETTOOL utility by entering the program name:
NETTOOL.NET.SYS
The root menu will appear.
3. Enter XPVAL to run the transport validation.
4. XPVAL will run a local program (XPVALLOC) and will prompt you for
the information it needs to perform the validation. To check the
local transport, enter information about the local loopback NI.
5. To check the transport between the local node and a remote node,
make sure XPVAL is running on the remote node as well and enter
information about the remote node.
6. XPVAL will run a one minute connection test to verify the
operation of the transport and report any errors it encounters.
See below for information on the error messages.
XPVAL Line Test Error Messages
Error messages for the XPVAL line tests appear in inverse video at the
system console. Some errors allow the test to continue, so they may
scroll off the top of the terminal screen. Copy the error message
information for further diagnosis.
Error Message Categories.
Errors from the XPVAL line tests fall into the following categories:
* Packet verification errors.
* Send and receive failures.
* Socket creation failures.
* Checksum errors.
* Miscellaneous errors.
Packet Verification Errors.
Packet verification errors indicate problems with either the packet size
or the character received. Packet Verification Errors will not abort the
XPVAL line tests. Their error messages may scroll off the top of the
console terminal screen, preceding a "TCP TEST FAILED"s or console
message. Packet verification errors are listed below:
Error Message
RECEIVE PACKET IS INCORRECT SIZE
Expected nn Bytes. Received mm Bytes.
Cause: Either message packet was partially lost, or "send"
and "receive" are not synchronized.
Action: Usually packets will resynchronize with the start of
the next segment of the test. However if errors
continue for each packet, check surrounding errors,
then rerun the test. If problems continue, see
appendix B, "Submitting an SR".
Error Message
RECEIVED PACKET NOT VERIFIED
First Byte not verified is: xx
Should be: y, received: z
Cause: Either byte in packet has changed (bit error) or
packets are unsynchronized.
Action: Usually packets will resynchronize with the start of
the next segment of the test.
However if errors continue for each packet, check surrounding errors,
then rerun the test. If problems continue, see appendix B, "Submitting
an SR".
Send and Receive Failures.
Most Send and Receive failures are timing-related. They usually do not
abort the tests. Listed below are the Send and Receive failures which do
not abort the tests:
Send and Receive Errors
TCP MESSAGE RECEIVE FAILED Packet # {Remote}
IPCSEND FAILED Packet # {Remote}
DATA RECEIVE FAILED Packet # {Remote, Local}
1ST MASTER SEND FAILED {Local}
SEND FAILED Packet # {Local}
Summary Messages:
TCP TEST FAILED
LOCAL: SEND TO REMOTE FAILED
LOCAL: RECEIVE FROM REMOTE FAILED
LOCAL: SEND AND RECEIVE FAILED
REMOTE: RECEIVE FROM LOCAL FAILED
REMOTE: END TO LOCAL FAILED
REMOTE: RECEIVE AND SEND FAILED
Note the location in the program where the error occurred. For each
error, examine the SOCKERR numbers and the Protocol Module numbers
returned. Save the error information. Follow the "Actions" for the
Protocol Module or NetIPC SOCKERRs, both listed in the NS3000/iX Error
Messages Reference Manual.
Socket Creation Failures.
Socket creation failures and Network IPC Connection errors cause a test
to terminate. Listed below are Socket Errors which abort the tests:
Socket Errors
UNABLE TO CREATE SOCKET {Local & Remote}
CONNECTION REQUEST FAILED {Remote}
RESPONSE TO CONNECTION FAILED {Remote}
LOCAL IPCRECVCN FAILED {Local}
Following these errors on the console screen are a SOCKERR and a Protocol
Module error. Copy the error messages on the user and system console
terminals. Follow the "Action" for the SOCKERR and PM errors,
respectively listed in "Network Interprocess Communication Errors" and
"Network Transport Protocol Errors" in the NS3000/iX Error Messages
Reference Manual.
Checksum Errors.
The XPVAL software line tests enable checksum in the TCP protocol of the
network transport subsystem. "Checksum" errors may be returned to either
console. If "Checksum" errors appear along with "Send and Receive
failures" listed above, then your system may have hardware link problems;
see "Investigating the Link" in appendix A of the NS3000/iX Error
Messages Reference Manual.
Miscellaneous Test Errors.
Certain errors may appear in all software line tests which do not fit in
the categories described above. They are listed below.
Error Message IPCERRMSG FAILED (SOCKERR # )
Cause: Error message could not be acquired from the message
catalogue SOCKCAT.NET.SYS.
Action: Ensure that the message catalog exists. Examine
errors returned to the console before and after this
error.
Error Message IPCSHUTDOWN FAILED
Cause: Socket could not be closed.
Action: Examine errors returned to the console before this
error. Take action for appropriate SOCKERR.
General Test Suggestions
If the following SOCKERRs appear together, then the network may be "too
busy" - that is, coordinating too many processes - to permit proper
operation of the XPVAL tests:
Error Message
REMOTE ABORTED THE CONNECTION
SOCKET TIMEOUT
and
CONNECTION REQUEST FAILED
RESPONSE TO CONNECTION FAILED
LOCAL IPCRECVCN FAILED
Wait until network activity lessens to execute the tests.
Examine the Protocol Module errors regarding the TCP entity. Protocol
Module errors are listed in the "Network Transport Protocol Errors" table
in the NS3000/iX Error Messages Reference Manual.
To Validate Network Services in Batch Mode
Follow the steps below to use QVALNS to check the Network Services. The
services tested are VT, RFA, NFT, RPM, and RDBA. (Note that it is not
possible to use passwords with QVALNS. If passwords are required, run
NSTEST instead.)
1. Make sure the network transport and Network Services are running
on all nodes that are to be a part of this test.
2. Run the NETTOOL utility by entering the program name:
NETTOOL.NET.SYS
The root menu will appear.
3. Enter QVALNS to run the Network Services validation in batch mode.
4. When prompted, enter the name of the destination node to which you
want to connect. (This is the same as entering the command RUN
QVALNS.NET.SYS;INFO=nodename outside of NETTOOL.)
5. QVALNS will stream a job that tests the network services. The
program will display any errors encountered on the system console.
To Validate Network Services Interactively
Follow the steps below to use NSTEST to check the Network Services. It
is possible to use passwords with this test.
1. Make sure the network transport and Network Services are running
on all nodes that are to be a part of this test.
2. Run the NETTOOL utility by entering the program name:
NETTOOL.NET.SYS
The root menu will appear.
3. Enter NSTEST to run the Network Services validation in interactive
mode.
4. When prompted, enter the name of the service you want to test.
You should always test VT first so that NSTEST can set up a remote
session.
5. When prompted, enter the name of the destination node to which you
want to connect.
6. When prompted, enter a logon string for the destination node.
Enter other values as required. The tool will test the Network
Service you selected.
To Test RDBA using NSTEST.
To test RDBA, the data base RDBAT must reside in the home group of the
remote system. This is not a problem when you run QVALNS, because that
program creates the database and then purges it when it finishes. If you
want to test RDBA using NSTEST, follow the steps below.
1. Obtain a temporary copy of the job JQVALNS.NET.SYS. If this file
is not available, run QVALNS to create it.
2. Find the commands in this job which purge the database. They will
be very near the end of the job. Delete these lines using your
favorite editor.
3. Stream the job you just edited. When it finishes, the database
will be intact so that NSTEST will run.
4. After NSTEST completes, purge the database to save space on your
disk.