The following figure shows a remote procedure executed synchronously. The application sets a simple status flag (Done) to indicate that the remote request has completed.

As an event-driven GUI application, the client first executes a WAIT-FOR statement after having set up code for handing events (1). When the client executes sync.p as a synchronous remote procedure (2), the client blocks while the server completes the request (3) and only continues execution after the remote procedure completes (4). Results from a synchronous remote procedure call are returned to the client immediately after the point of invocation (4), exactly as they are returned from a local procedure call.

Note that in this example all of the remote processing and handling of the result occurs in the trigger for bStatus. While straight forward to implement, the client can block for an indeterminate period of time at the synchronous RUN statement waiting for sync.p to complete, depending on the application. Asynchronous requests allow a client to avoid this bottleneck.

Figure 1. Synchronous requests