Resolving failed connections by clients or administrators
The two main cases for connection failures are general failure, where no connections at all are allowed, or an isolated failure where some connections are allowed but others fail.
If no connections at all are possible, it might be necessary
to run the server in the foreground so that a server console is available,
and additional diagnostic steps can be taken. Check the settings to
verify the proper configuration for communicating with the server:
- Ensure that the server is able to bind to a port when it is started.
If it is unable to bind to a port, then it is likely that some other
application is using that port. The server can not bind (use) a given
TCP/IP port if another application is already bound to that port.
If the server is configured for TCP/IP communications and successfully
binds to a port on startup for client sessions, the following message
is issued:
If a given communication method is configured in the server options file, but a successful bind message is not issued during server startup, then there is a problem initializing for that communication method.ANR8200I TCP/IP driver ready for connection with clients on port 1500. - Verify that the code TCPPORT setting in the server options file is correct. If the code setting is inadvertently changed, the clients fail to connect. That is because the clients are trying to connect to a different TCP/IP port than the one the server is listening on.
- If multiple servers are using the same TCP/IP address, ensure that the TCPPORT and TCPADMINPORT for each server are unique. For example, there are two servers at the same TCP/IP address. The first server has a TCPPORT of 1500 and a TCPADMINPORT of 1500. The second server has a TCPPORT of 1501 and a TCPADMINPORT of 1500. The first server to grab port 1500 locks out the other server from port 1500 and clients can no longer access the first server. Administrative clients always connect to the second server. A better choice of ports for each server would be 1500 and 1501 for TCPPORT; 1510 and 1511 for TCPADMINPORT.
- Check that the server is enabled for sessions. Issue the QUERY
STATUS command and verify that
Availability: Enabled
is set. If the result statesAvailability: Disabled,
issue the ENABLE SESSIONS command. - If specific clients are unable to connect to the server, check the communication settings for those clients. For TCP/IP, check the TCPSERVERADDRESS and TCPSERVERPORT options in the client options file.
- If only a specific node is rejected by the server, verify that the node is not locked on the
server. Issue the QUERY NODE
nodeName command, where nodeName is the name of the node to
check. If the result states
Locked?: Yes,
then evaluate why this node is locked. Nodes can be locked in following scenarios:- If server administrator issues the LOCK NODE administrative command.
- If someone attempts to login by using the wrong password more than the number of times specified by the SETINVALIDPWLIMIT command. For more information about the number of invalid logon attempts, see SET INVALIDPWLIMIT (Set the number of invalid logon attempts).
To view the messages in the server activity log, issue the QUERY ACTLOG command. This might provide additional information about the actual cause to lock the node. If the node is locked due to invalid logon attempts, evaluate to identify that those attempts are made by authorized user or unauthorized user. If the attempts are made by unauthorized user consider to change the password before unlocking the node.
If it is appropriate to unlock the node, issue the following command:
UNLOCK NODE <node_name>where <node_name> is the name of the node to unlock.
- If the computer on which the server is running is having memory or resource allocation problems, it might not be possible to start new connections to the server. The memory or resource allocation problem might be cleared up temporarily if you either halt and restart the server, or if you halt and restart the computer itself. This action is a temporary solution, and diagnosis should be continued for either the operating system or the server because the memory and resource allocation problem might indicate an error in either.