Try OpenEdge Now
skip to main content
Application Migration and Development Guide
Application Development with PAS for OpenEdge : Design and Implementation Considerations : Distributed application design and implementation : Understanding condition handling in distributed ABL sessions
 
Understanding condition handling in distributed ABL sessions
The processing boundary that exists between an ABL client application session and a PAS for OpenEdge session influences how error conditions are viewed and handled in each session. The following table defines the four basic ABL conditions and describes how raising these conditions in one session affects the processing in the other, associated session.
Table 20. ABL conditions
Condition
Description
ERROR
An unhandled ERROR condition raised in a client application has no effect on any server sessions to which it is connected. Conversely, an unhandled ERROR condition raised in a server session has no effect on the client application to which it is connected.
Handling this condition conforms to standard ABL rules. For more information about these rules, see OpenEdge Getting Started: ABL Essentials.
The only way a server session can raise ERROR in the client application is for a remote procedure or an Activate procedure to execute the RETURN ERROR statement. Either one raises ERROR on the RUN statement in the client application, which can also be returned in a CATCH block on the client..
ENDKEY
An unhandled ENDKEY condition raised in a client application has no effect on any server sessions to which it is connected. Conversely, an unhandled ENDKEY condition raised in a server session has no affect on the client application to which it is connected.
Handling this condition conforms to standard ABL rules. For more information about these rules, see OpenEdge Getting Started: ABL Essentials.
A server session raises the ENDKEY condition if an attempt to find a database record fails or an INPUT FROM statement reaches the end of an input stream. Like a batch client, there are no user-interface events that can raise the ENDKEY condition.
STOP
A STOP condition raised in a client application while it is executing a remote procedure causes a STOP condition to be raised in the context of the executing procedure in the server session.
An unhandled STOP condition in a server session results in the request being returned with the STOP condition.
On a root client application — An unhandled STOP condition causes OpenEdge to restart the client Startup Procedure (-p). This restarted session retains connections with databases, but deletes outstanding persistent procedures. This restart also disconnects any server sessions it is connected to and deletes active remote persistent procedures.
In a server session — An unhandled STOP condition causes the STOP condition to be propagated back to the client application where it is raised again in the context of the outstanding remote procedure request. It does not cause a restart of the server session. All active remote persistent procedures and server session connections remain intact.
QUIT
An unhandled QUIT condition raised in a client application disconnects the client application from all server sessions it is connected to and deletes the proxy procedure handles for that client application.
An unhandled QUIT condition raised in a server session results in the immediate, successful completion of the current remote procedure request. The client application is then automatically disconnected from the server session.
Note: Executing QUIT as the final statement in the Disconnect procedure for a bound session-managed connection causes the AVM to clear all context, such as globally shared variables, from the server session before it disconnects from the client.