HP 3000 Manuals HP 3000 Manuals
Common Problems and Actions
Invalid Software Installation
A software installation may be invalid. Run NMMAINT.PUB.SYSto obtain a
listing of version IDs for NMS and for all of the NMS dependent
subsystems.
Locate the overall version IDs for each subsystem. Check that these
subsystems are the correct version for operation with the associated
link.
MPE/iX Configuration Incorrect
Refer to System Startup, Configuration, and Shutdown (32650-90042) to
obtain an I/O listing of the system. Check that the drivers are
correctly configured.
Insufficient MPE/iX Resources
There may be insufficient MPE/iX resources, such as configured table
sizes. Refer to the recommendations for system tables provided in System
Startup, Configuration, and Shutdown. Reconfigure MPE/iX to fix any
problems found and restart the system.
Corrupt Configuration File
The configuration file is possibly corrupt. If the error persists, use
NMMGR to manually check the configuration file (if possible). Check to
see that all data records have been created. If bad records seem to be
localized to a particular item, delete that item and reconfigure it. If
necessary, RESTORE a known good backup copy of the file.
Corrupt Network Directory File
If the network directory file is open in NMMGR during a system failure,
starting the network transport with NETCONTROL START does not recover the
network directory file. Run NMMGR in maintenance mode as follows:
:FILE NMMGRCMD=$STDINX
:RUN NMMGR.PUB.SYS
NM Configuration Manager 32098-20012 A.02.00 (C) Hewlett Packard Co. 1986
NMMGROPENDIR NSDIR.NET.SYS
NETWORK DIRECTORY: Recovering file NSDIR.NET.SYS
NMMGREXIT
After recovering the file, stop and restart the network transport as
described in chapter 2 of this manual.
Incompatible Configuration File Version
Run the NMMGRVER.PUB.SYS program to convert the old configuration file to
the new format. Refer to the Using the NMS Utilities manual for more
information.
Insufficient Configuration File Values
Only change the configured values in the configuration file for a
persistent or widespread problem. The configured values apply to
communication over all the connections and with all the remote nodes in
the internet. The default values are calculated to provide good
performance in a variety of situations. Changes to these values may
improve one situation but affect other situations adversely. If the
recommended action for a particular error or log message is to change the
configured value, do so only for an extremely high number of log messages
or for repeated error messages. Consult your HP representative for more
information.
Retransmission Timeout Errors
The network transport provides reliable end-to-end communication. As
part of ensuring reliable receipt of packets, the transport protocol TCP
keeps track of the packets transmitted. If TCP does not receive an
acknowledgment within the configured time period, TCP retransmits the
packet. If the packet is retransmitted the maximum number of times
configured and is still unacknowledged, then TCP logs a retransmission
timeout error and aborts the connection.
The transport protocol PXP may also log a retransmission timeout error.
This occurs in much the same way as described for TCP, although PXP
retransmits requests, not packets, and waits for replies, not
acknowledgments. PXP is only used whenever an IPCLOOKUP is issued as
part of a NetIPC application, and only communicates with the socket
registry.
Retransmission timeouts can occur for the following reasons:
* Packets were transmitted to a remote node which was not active or
which terminated before the packet arrived.
* Excessive node loads took place during connection establishment.
* The remote node experienced congestion or lack of buffers.
* Possible link or configuration problems.
If a retransmission error is returned in a log message or in an IPCCHECK
error code for NetIPC applications, first check that the remote node is
up and that its transport has been started. If so, check if the
retransmission timeout error is an isolated event or an ongoing problem.
Examine a formatted log file for the period up to and including the
error.
If the problem is ongoing, then take the appropriate action:
* If the log messages show initial TCP connection failures due to a
heavily loaded remote node, configure a longer Initial
Retransmission Interval for the Transmission Control Protocol
(TCP) Configuration Screen. This is in the NETXPORT branch of the
NMMGR network configuration. Also, you can increase the
connection assurance interval on this screen if there are a large
number of TCP connections configured.
* If there are IPCLOOKUP failures, and the log messages show PXP
timeouts due to a heavily loaded remote node, configure a longer
default retransmission interval for the PXP data screen. This is
also in the NETXPORT branch.
* If the problem affects established connections and none of the
above conditions apply, then configure a longer retransmission
interval upper bound, or configure a higher number of maximum
retransmissions per packet for the Transmission Control Protocol
(TCP) Configuration Screen.
NetIPC Errors
NetIPC programmatically creates processes on both local and remote
systems. These processes must be released, along with any descriptors
and resources, after the program completes. Unless these process are
terminated properly, errors may result.
NetIPC Shutdown Errors.
The NetIPC call IPCSHUTDOWN releases a descriptor and any resources that
are associated with it. Since system resources are used as long as call
sockets and destination sockets exist, it is important that application
programs release the sockets whenever they are no longer needed.
Before a process terminates, it should terminate its connection with
IPCSHUTDOWN. Because this termination takes effect very quickly, all of
the data that is in transit on the connection is lost when the connection
is shut down. As a result, the processes that share a connection must
cooperate to ensure that no data is lost. Indications of a faulty
shutdown procedure on an individual or application level are:
* If you receive log messages or NetIPC error codes where the
recommended action for some of the log messages is to increase the
number of TCP connections, and the connections are not currently
active.
* If the TCP PM log message indicates that a packet was received
after the IPCSHUTDOWN call but before the TCP connection was fully
deleted.
Indication of a faulty shutdown procedure on a nodal level is an
incomplete shutdown of the network transport.
Network Transport Shutdown
Shutting down the network transport via the NETCONTROL STOP command
requires that all NetIPC call sockets, all TCP connections, and all PXP
sockets are closed. An error (Transport Shutting) is returned to all
open sockets. Until this error is received by the user and the reply
sent to TCP/PXP by NetIPC, the network transport does not terminate. The
Network Services shut down completely even if an NSCONTROL ABORT has not
been issued. However, it is important that user applications always have
a send or receive posted on any open socket so that the shutdown error is
delivered to them.
The only way to tell if the network transport has completely shut down is
to check the log file for the Control Process; Transport Stopped and the
TCP SIP/ General Protocol Stop nodal log messages. If these messages
have not been logged, the network transport is waiting for an open socket
and cannot completely terminate. The network transport may be
re-initialized even though the "old" transport has not completely
terminated. The two versions do not interfere with each other, and the
old one goes away when its last open socket is finally closed. This old
transport does not use any CPU and does not retain "ownership" of the
links, but the data structures that wait on the open connection do use
virtual memory.
If you find any of these indications, check any NetIPC applications for a
faulty shutdown procedure. Refer to the NetIPC3000/iX Programmer's
Reference Manual.