Progress 4GL/ABL is Inherently Single Threaded, Fat Client¶
Single Threaded¶
All Progress 4GL/ABL programs are single threaded. There are no multi-threading facilities in the 4GL. For example, there is no way to start a thread that runs 4GL code in the same process or to block an ABL thread while another thread in the same process executes other ABL code.
When a program is executed in Classic Appserver or WebSpeed mode, there is still a separate ABL process for each agent. Each of these ABL processes can only ever execute a single thread that runs 4GL code.
PASOE implements a multi-session agent (MSA) but each session is single-threaded. Only 4GL code running in the PASOE MSA can be considered true server-side code (not fat client).
Fat Client¶
When you manually run a Progress 4GL program, you start up a binary executable (for example, _progres on Linux or UNIX and prowin32.exe Windows). That executable reads the program's file (source code or r-code) and interprets it. That program runs on the physical system on which the executable is launched. It runs within the context of the operating system's logged in user that launched the executable. This means that the Progress program can only access resources that the current user is permitted to access. This "manually" started program could be interactive (a ChUI or GUI client) or it could be non-interactive (a batch mode client). Either way the program conceptually runs as a client process in the context of some operating system user. All 4GL logic for the program runs inside of that client process and there is one process for each user.
It is common for Progress developers to use the term "client/server" to describe this original implementation approach. In this concept, interactive or batch clients connect to a multi-user database process, which is considered the server part of client/server. Technically, the Progress database is a server but the split of the functionality between the database server and the client is heavily weighted toward the client side. One of the biggest benefits of the 4GL is the 4GL's use of the same language for both business logic and for data access. For example, WHERE clause expressions in queries are written in 4GL. The non-obvious implication of this design is that any execution of the WHERE clause is done in the client process and not on the database server. The database server can really be considered an advanced indexing engine, it lacks much of the filtering and sorting capabilities that SQL developers take for granted. This means that many more records must be returned by the database to the client and the client handles the filtering. The 4GL compiler attempts to minimize the negative impact of this design decision by implementing equality and range matching using indexes so that certain WHERE clause terms can be used to only walk only a sub-set of the records in that index. All the rest of the 4GL WHERE clause is still executed in the client process and only some queries can take advantage of this feature. Likewise, if client-side sorting is to be avoided the query must be written to implicitly select an index that provides the same sorting that is needed by that query. In both cases, the real logic is implemented on the client.
We call this "inherently fat client" because outside of the PASOE MSA, there is always a per-user/per-session client process that executes all 4GL logic. As of 2026, most applications do not run all of their logic in PASOE MSA mode. By design, even the WHERE clause processing is done by interpreting the 4GL expression in the client process instead of delegating it to the database server. The database server can best be considered an advanced index engine that coordinates index-based access on a record-by-record basis. The approach is designed in the core of OE, the database and its 4GL language implementation.
For GUI and ChUI applications, the interactive UI is tightly coupled to this fat client design.
Classic Appserver and PASOE¶
When Progress implemented Appserver and WebSpeed, they did not eliminate this design choice. There is still a separate process running for each 4GL program being executed. The fact that one now can call it over the network to invoke a program there, does not eliminate the fact that it is still a fat client. Progress just added a kind of pool of fat clients (agents) and a broker to distribute requests.
With the latest Pacific Application Server for OpenEdge (PASOE), 4GL code executes on different threads in the same process. Each thread in the PASOE process effectively corresponds to an appserver agent in classic appserver mode. PASOE leverages a Java implementation in Tomcat to replace the classic mode broker/agents architecture with a multi-threaded single process that does the dispatching and then one or more PASOE processes that are multi-session agents (each simultaneous session runs on a different thread). PASOE only affects 4GL code running in the appserver. Batch processes and any interactive clients (ChUI or GUI) are all still executed in their own single-threaded client process.
© 2004-2026 Golden Code Development Corporation. ALL RIGHTS RESERVED.