Timeout Problems

If you are logged off involuntarily while using Sterling Connect:Direct® via TCP/IP, your problem may be related to the TCP/IP connection not being able to communicate with the DTF. If you see the message TCP/IP SEND error; Connection Lost, and press F1 to see the help for this message, the following text is displayed for message SVTC006I:

 MSGID  ==> SVTC006I
 MODULE ==> DMTSTSND
 TCP/IP SEND error; Connection Lost
An error has been detected while sending a command via TCP/IP.
The TCP/IP connection has been lost.  A possible cause is
Connect:Direct has been shutdown and all TCP/IP connections
have been closed.
System Action: Normal processing can not continue.
Response: Logoff and attempt to signon again.

Although the TCP/IP protocol does not have a mechanism to send you a console message indicating that the client has been dropped and your session has timed out, you can determine if this has happened to you by looking in the statistics file for a signoff record with an SAFA019I error message that matches your user ID (be sure to enter Y in the CHANGE EXTENDED OPTS field on the SELECT STATISTICS panel and then enter SO as a record type on the next screen). For more information, go to the IBM® Sterling Connect:Direct for z/OS® Administration Guide and search for Signon and IUI/API Errors.

Sterling Connect:Direct provides an inactivity timer that is based on the number of minutes a user can remain inactive without communicating with the DTF. An administrator can specify this value using the TCP.API.TIMER global initialization parameter. Sterling Connect:Direct will only recognize changes made to the TIMEOUT parameter by an administrator. If you attempt to change this parameter and you are not an administrator, you will not be able to sign on. You can determine if this has happened to you by looking in the statistics file for a signon record with an SAFA020I error message that matches your user ID. For more information, go to the IBM Sterling Connect:Direct for z/OS Administration Guide and search for Signon and IUI/API Errors.

Note: The rationale behind the timeout feature is to do housekeeping to keep the number of hung sessions to a minimum and avoid the limit specifying the maximum number of users that can be signed on to Sterling Connect:Direct. Without the timeout feature, an administrator would have to recycle the DTF to allow TCP/API logons to reconnect once the MAXUSER limit was reached.