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:
```
ANR8200I TCP/IP driver ready for connection with clients on port 1500.
```
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.
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 states "Availability: 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 only be locked by using the LOCK NODE administrative command. If it is appropriate to unlock this node, issue the UNLOCK NODE nodeName command, where nodeName 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 IBM® Tivoli® Storage Manager server because the memory and resource allocation problem might indicate an error in either.