Did this article resolve your question/issue?



How to use the ClientTimeOut Startup Parameter.

« Go Back


TitleHow to use the ClientTimeOut Startup Parameter.
URL NameP15531
Article Number000132077
EnvironmentProduct: Progress
Version: 7.x, 8.x, 9.x
Product: OpenEdge
Version: 10.x, 11.x
OS: Windows
Question/Problem Description
How to use the ClientTimeOut Parameter.
How to disconnect Remote ABL Clients after inactivity period exceeded.
How to manage dead Remote Client connections.
How to terminate inactive Remote Client sessions.
How to prevent locked records held by dead Remote Clients before network timeouts are exceeded ?
What methods are available to automatically disconnect dead Remote Clients?
Steps to Reproduce
Clarifying Information
Error Message
Defect/Enhancement Number

It's important to differentiate between:

  • "idle" (ie connected but inactive) and 
  • "dead" (ie no longer connected, but still in the database shared memory). 

An OpenEdge database cannot detect a dead remote client connections, instead, it relies on the network protocol to notify the database that a remote user has died or disconnected. Refer to Article  How to configure the Operating System TCP KEEPALIVE   

This Article discusses a method of controlling remote ABL client sessions through the assumption that if the connection has exceeded x-time of inactivity to the database, then the client is probably either (a) idle (b) hanging or (c) terminated abnormally (crashed).

The ClientTimeOut parameter allows the database remote server process to determine whether a remote ABL client has been inactive for a specified period of time and if so, the remote server disconnects that remote client and backs out any related active transaction releasing associated locks/latches it may be holding at the time. Client "inactivity" is treated as the client not accessing the database for a specified period of time.

On Windows the ClientTimeOut parameter is a REGISTRY key entry only, where the value is in minutes. 

As of this writing (OpenEdge 11.7), there is no Progress equivalent of ClientTimeOut on U/Linux. This is purely a windows function to manage idle connections. 

ClientTimeOut functionality was broken in Progress 9.1B/9.1C and fixed in Progress 9.1D02.

If a client remotely connects to two or more databases and currently works only with one of them, the client will be stopped as "inactive" in other database(s) and the following will appear in the database log file:

Client <num> was inactive for more than <num> minutes (4435).

If the databases are started/managed by the AdminServer, since the AdminServer does not read the registry but gets it's information from the properties files and ClientTimeOut is not a standard parameter, it cannot be added to the "Other Arguments" or as an entry in the file, because it is expected only as a registry entry on the Database Server machine.

The ClientTimeOut parameter only manages remote ABL connections. If batch processes are run as shared memory connections they will not be terminated. Instead, the WatchDog functionality will clean up dead shared memory connections but not idle connections.


The parameter uses the following syntax:



Where n is the number of minutes a client can be idle before the remote server disconnects it.

The ClientTimeOut parameter needs to be added to the registry of the Database Server machine as a "String Value", in one of the following keys. By default this string will not exist and needs to be created.




Where <version> is the current version (e.g. 11.3).

1)  Create a "String Value" with the CamelCaps name: ClientTimeOut

2)  Assign a value to the ClientTimeOut String which is a number <n> that represents the number of minutes to wait before disconnecting an idle client (e.g. 3 minutes = "3" as the value for the string)

Alternate methods include:

  • Firewall settings that terminates idle TCP connections.
  • Application-side triggers that cause the application session to terminate after a delay if the user does not interact with it.
References to Other Documentation:

Progress OpenEdge -> Managing ABL Applications -> ABL and R-code Deployment and Management -> Maintaining User Environments -> Maintaining the Windows user environment -> Using the INI2REG utility -> Maintaining the progress.ini file -> Startup section:

Last Modified Date11/20/2020 7:30 AM
Disclaimer The origins of the information on this site may be internal or external to Progress Software Corporation (“Progress”). Progress Software Corporation makes all reasonable efforts to verify this information. However, the information provided is for your information only. Progress Software Corporation makes no explicit or implied claims to the validity of this information.

Any sample code provided on this site is not supported under any Progress support program or service. The sample code is provided on an "AS IS" basis. Progress makes no warranties, express or implied, and disclaims all implied warranties including, without limitation, the implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample code is borne by the user. In no event shall Progress, its employees, or anyone else involved in the creation, production, or delivery of the code be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample code, even if Progress has been advised of the possibility of such damages.