|
|
If you are using the interactive capabilities of NS 3000/iX
and associated links and receive an error, refer to "NS 3000/iX
Network Services Error Messages" in the NS 3000/iX
Error Messages Reference Manual.
The command errors fit into four categories:
Syntax errors or invalid options. These errors result from
user errors when issuing the command. They are readily corrected by
checking for the correct syntax and reissuing the command.
Warnings. If a command is executable but may give
unexpected results, a warning is issued. This would occur in a
situation where conflicting options were specified. The warning
informs you which option was actually used (or not used).
Resource Errors. These errors occur when a system resource
needed for the execution of the command is not available. If they
occur, you can wait and reissue the command later, when the resource
may be available. If resource errors happen frequently the
configuration or resource allocation of the system may be inadequate.
The network manager may need to investigate further.
Internal Errors. These errors indicate that the software is
malfunctioning. If they ever occur, notify your HP representative.
The network manager should follow the steps outlined in
Appendix B "Submitting an CR""
For syntax errors and warnings, consult the reference pages in this manual for
that command's correct syntax and options, or refer to Using NS 3000/iX
Network Services.
Line Opening Errors
There are several reasons why a DSLINE command for opening a
communications line might be rejected. Some line opening errors actually occur
when a REMOTE HELLO (or DSCOPY, or programmatic
RPMCREATE or FOPEN) is executed, not when the DSLINE
is done. The following list summarizes the likely causes of line opening
failures:
The user made a syntax error in the DSLINE command.
The user specified an erroneous nodename or
envid in the DSLINE command. The node name
must match the one configured for the system the user is trying to
reach. Make sure that all users know the correct node names. You may
want to post a map with the configured node names for all the nodes
on the network. The correct node names can be checked in the network
directory (if one is being used).
A network was not started by the local console operator, the
remote console operator, or any intermediate nodes. Check that all
required commands have been issued on the local, remote, and
intermediate nodes. The network interfaces, the LAN NI, the loopback
NI, point-to-point NI, X.25 NI, token ring NI, and gateway half NI,
must be initialized with NETCONTROL START commands.
The DTC/X.25 Network Access card in the DTC must be started; refer to
Using the OpenView DTC Manager or Configuring and Managing
Host-Based X.25 Links. The Network Services must be initialized
with the NSCONTROL START command. Some links may also need to
be started by NETCONTROL ADDLINK commands. Links can be
configured not to be started when a NETCONTROL START command
is executed and be started via NETCONTROL ADDLINK. Links may
have been closed by NETCONTROL DELLINK or may have been closed
because an irrecoverable error was detected on the line.
The remote node may not be operational.
The remote operator may have lowered the session limit. This would
cause a failure in a REMOTE HELLO or a DSCOPY or
RPMCREATE that tried to automatically log on to a
session.
The local console operator may have used the service list of the
NSCONTROL command to limit the Network Services to incoming
users only. On the remote node, the operator may have limited the
Network Services to outgoing only. This would cause a
REMOTE HELLO, DSCOPY, remote FOPEN, or
RPMCREATE to fail, depending on which services were not
started.
If the line is a dial up line, a failure in a REMOTE HELLO,
DSCOPY or RPMCREATE can be caused by the following:
If auto dial, the number was busy, wrong, or was never
answered at the remote computer.
The security strings did not match at either the local or
remote node (if security was enabled).
The IP address of the remote node was not configured as a
candidate for use of this link.
If the link is a shared dialup link, a failure will occur if
the link is connected to a node different than the one issued in
the DSLINE command.
When a REMOTE HELLO is issued which causes the phone
to be dialed, there is a window in which subsequent
REMOTE HELLOs from other users will be rejected. The
window is from the time the auto dial starts (or dial request) to
when the connection is established.
A REMOTE HELLO, DSCOPY or RPMCREATE will fail if
the IP address of the remote node configured in the network directory
does not match the IP address of the remote node configured in the NS
Configuration file.
All virtual terminals on the remote node are already in use, which
means there are no remote resources available to establish a remote
session. This would cause a failure in a REMOTE HELLO or a
DSCOPY or RPMCREATE that tried to automatically log
on to a session.
Someone has exclusive access to the specified line or the user
requested exclusive access to a line that is already in use.
Someone is exclusively accessing a server program. For example,
someone is executing the STORE command or a SYSGEN
system backup on DSSERVER.NET.SYS.
There is a hardware problem — the communications device is not
responding correctly.
Line Closing Errors
There are several reasons why a DSLINE command for closing a
communications line might be rejected. The following list summarizes the likely
causes of line closing failures:
The user made a syntax error in the DSLINE command.
The user specified an erroneous nodename or
envid in the DSLINE command. The nodename must
match the one configured with NMMGR. Make sure that all users know
the correct nodenames. You may want to post a map with the configured
nodenames for all the nodes on the network.
The remote node may not be operational.
There is a hardware problem — the communications device is
not responding correctly.
NMS Utility Errors
A file system error (FSERR) may have occurred while attempting
to access the configuration file. Try to access the configuration
file under the same user ID using NMMGR. Use the NMMGR Error screen
to find out what the underlying FSERR is. A complete listing of
NMS error messages is available in Using the Node Management
Services (NMS) Utilities. Correct the problem and retry.
|