Try OpenEdge Now
skip to main content
Developing AppServer Applications
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 an AppServer 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 16. ABL conditions
Condition
Description
ERROR
An unhandled ERROR condition raised in a client application has no effect on any of the AppServer agents to which it is connected. Conversely, an unhandled ERROR condition raised in an AppServer agent 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 an AppServer session can raise ERROR in the client application is for a remote procedure or an Activate procedure to execute the RETURN ERROR statement. This raises ERROR on the RUN statement in the client application.
ENDKEY
An unhandled ENDKEY condition raised in a client application has no effect on any of the AppServer agents to which it is connected. Conversely, an unhandled ENDKEY condition raised in an AppServer agent 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.
An AppServer 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 AppServer session.
An unhandled STOP condition in an AppServer 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 AppServer agents it is connected to and deletes active remote persistent procedures.
In an AppServer agent — 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 AppServer session. All active remote persistent procedures and AppServer agent connections remain intact.
QUIT
An unhandled QUIT condition raised in a client application disconnects the client application from all AppServer agents it is connected to and deletes the proxy procedure handles for that client application.
An unhandled QUIT condition raised in an AppServer session results in the immediate, successful completion of the current remote procedure request. The client application is then automatically disconnected from the AppServer agent.