Common Problems and Actions
MPE documents | |
 Complete PDF | |
| Table of Contents | |
| Index |
Invalid Software Installation
A software installation may be invalid. Run NMMAINT.PUB.SYS to 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 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 NMMGR>OPENDIR NSDIR.NET.SYS NETWORK DIRECTORY: Recovering file NSDIR.NET.SYS NMMGR>EXITAfter recovering the file, stop and restart the network transport as described in Chapter 2 "Operating Your Network" 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 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.
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 NetIPC 3000/XL Programmer's Reference Manual.
|
Investigate the Software |
Chapter 6 Using NETTOOL |