Verifying Network Connections and Services

Several line verification tests are available to help you verify the operation of NS 3000/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

Perform the following steps 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 “Using NETTOOL ” for more information.)

Make sure the network transport is active on this node and on any other node that will be a part of this test.
Run the NETTOOL utility by entering the program name:
NETTOOL.NET.SYS
The root menu will appear.
Enter XPVAL to run the transport validation.
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.
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.
XPVAL will run a one minute connection test to verify the operation of the transport and report any errors it encounters. See 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:

MESSAGE: RECEIVE PACKET IS INCORRECT SIZE Expected nn Bytes. Received mm Bytes.

Level:

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 ”

MESSAGE: RECEIVE PACKET NOT VERIFIED First Byte not verified is: xx Should be: y, received: z.

Level:

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 NS 3000/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 NS 3000/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 the NS 3000/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 here.

MESSAGE: PCERRMSG FAILED (SOCKERR #)

Level: 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.

MESSAGE: IPCSHUTDOWN FAILED

Level: SOCKERR #

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 NS 3000/iX Error Messages Reference Manual.

To Validate Network Services in Batch Mode

Perform the following steps 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.)

Make sure the network transport and Network Services are running on all nodes that are to be a part of this test.
Run the NETTOOL utility by entering the program name:
NETTOOL.NET.SYS
The root menu will appear.
Enter QVALNS to run the Network Services validation in batch mode.
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.)
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

Perform the following steps to use NSTEST to check the Network Services. It is possible to use passwords with this test.

Make sure the network transport and Network Services are running on all nodes that are to be a part of this test.
Run the NETTOOL utility by entering the program name:
NETTOOL.NET.SYS
The root menu will appear.
Enter NSTEST to run the Network Services validation in interactive mode.
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.
When prompted, enter the name of the destination node to which you want to connect.
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, perform the following steps.

Obtain a temporary copy of the job JQVALNS.NET.SYS. If this file is not available, run QVALNS to create it.
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.
Stream the job you just edited. When it finishes, the database will be intact so that NSTEST will run.
After NSTEST completes, purge the database to save space on your disk.