Distributed Processing

In a distributed processing environment, AcuConnect is a runtime server that handles user requests to start new runtimes on server machines. AcuConnect supports multiple runtime instances so that users may start multiple applications on the server at the same time. It also allows programs on one server to start programs on another server, ad infinitum, as long as each server has a copy of AcuConnect installed.

In distributed processing, both the client and the server have a copy of the ACUCOBOL-GT runtime. The runtime version on the client should match the version of the runtime on the server. If your application interfaces with C-ISAM or other special library routines, you must relink the runtime with the library routines you are using.

Because both the client and the server have an ACUCOBOL-GT runtime, you decide how much of an application runs on the client and how much on the server. The client can be as "thin" or as "thick" as you like. With AcuConnect in distributed processing, the client is actually a "smart" client.

To launch a server program, the client uses standard COBOL CALL syntax. You embed a CALL in the client application, and AcuConnect launches the server application for you automatically. All application (and data) access is completely transparent to the end user.

Differentiation is achieved through configuration files and, more precisely, through definition of either a CODE_PREFIX variable or a "code name alias," which defines the directory containing the object programs. Without modifying or recompiling the original code, the same object can operate on any server, client, or stand-alone machine.

The AcuConnect process can be described as follows:

A network administrator starts AcuConnect on the server. On Windows servers, this can be accomplished through an application service. On UNIX, the administrator uses the acurcl command along with options. For instance, he or she may enter:
```
acurcl -start -c acurcl.cfg -e server.err
```
The user starts the ACUCOBOL-GT client application on the client. In Windows, he or she clicks an icon. In UNIX, her or she enters a runcbl command. For instance:
```
runcbl -c client.cfg prog1.acu 
```
The client application, prog1.acu in this example, performs a remote CALL to the server application. For instance:
```
CALL "prog2.acu" using customer-info.
```
AcuConnect automatically starts the remote application, prog2.acu, on the server using the runtime flags and configuration file specified in client.cfg.
The remote application performs the requested task and returns a response to the client. If programmed accordingly, the remote application may perform a CALL to another application on the same or different server before sending back a response.
The client program processes the result, possibly displaying it to the user.

Synchronous or Asynchronous Operation

In the example shown above, the client application waits in a suspended state until the remote application performs its task and returns a result (that is, a "synchronous" CALL is performed). If desired, you can allow the client application to continue running by CALLing the C$ASYNCRUN library routine along with the remote application. In this case, you specify the "handle" of the remote application, as well as the application name itself. For instance:

CALL "C$ASYNCRUN" using handle-of-prog2 "prog2.acu" customer-info.

C$ASYNCRUN tells AcuConnect to allow asynchronous processing. If you use C$ASYNCRUN, you can check the status of the server application using the companion routine, C$ASYNCPOLL. See Synchronous or Asynchronous Execution for more information.