When you open a non-TLS connection from an ABL client to an ABL TLS server, you can initiate a situation that can result in an deadlock condition that is unbreakable from with in the application. This condition results from the following sequence of events:

1. The non-TLS ABL client connects a socket to a server socket on an ABL server using the CONNECT() method.
2. The client immediately follows the CONNECT() method by a READ() method on the socket object.
3. The ABL server enables TLS connections using the ENABLE-CONNECTIONS() method.
4. The server immediately follows the ENABLE-CONNECTIONS() method by a WRITE() method on the server socket object.

After Step 2, the non-TLS client begins waiting for the socket server to send it data. After Step 4, the socket server waits in a read mode (despite the WRITE()) for the client to begin an TLS connection operation. This results in both ABL sessions waiting for data from the other. For both the ABL client and server, the application hangs because ABL does not provide a socket timeout feature.

There is no way to detect this situation once the deadlock has occurred. However, the basic strategy for handling it is to know ahead of time that the server is running an TLS session. You can use the following techniques to determine the state of the server before continuing from the client:

• On the ABL socket server, use the SET-CONNECT-PROCEDURE() method to handle a CONNECT event asynchronously and watch a manual timer to determine if the ABL socket server is hanging.
• On the client side, you can also use a small procedure to test the connection before continuing with running the application.