Cobol-RPC adds a new dimension to Acucobol programming. You can choose where your programs should execute, on the client or a server. While this flexibility requires little or no additional coding, client and server programs have different purposes and these should be considered in determining how to redeploy an existing application or how to create a new one.
The difference between a Cobol-RPC client program and a traditional Cobol program is that Cobol-RPC clients have to call remote programs located on the server. Client programs are not restricted in any way.
So how does a client program call a remote program? Amazingly enough, the same way it calls a local one, with the standard Cobol CALL statement.
Because of the flexibility of the Acucobol runtime systems, Cobol-RPC can actually cause standard Cobol CALL statements to function as remote program calls.
Let's look at an example.
In standard Cobol programming, if a Cobol program needs to call another Cobol program called SAMPLE2, it uses the following statement:
CALL "SAMPLE2" USING ...
This statement causes the Cobol runtime system to load and execute SAMPLE2.
With Acucobol, Cobol-RPC can intercept this CALL statement before the runtime system executes it, and execute it instead as a remote program call. Cobol-RPC will do this because SAMPLE2 is identified as a remote program in the [RemotePrograms] section of COBOLRPC.INI.
In order to free system resources as quickly as possible and make them available to other processes, a client program should execute the SHUTDOWNRPC function before exiting. Failure to do this will delay the release of system resources until the Cobol-RPC client DLL is freed from memory. If other client processes are using Cobol-RPC the DLL is not freed from memory until all client processes are terminated.
The SHUTDOWNRPC function is executed as follows:
When a server program is called by a client it will usually be passed data to operate on. With Cobol-RPC the server program receives that data in the most natural location possible, the Linkage Section.
A server program should declare parameters passed by the calling program in the Linkage Section just as if the server program were being called through a normal CALL statement.
Cobol-RPC lets client programs call remote programs as if they were local. It is important to remember that these programs do execute on the server. When a client program opens a file it opens that file on the client, since that is where the client program is running. When a server program opens a file it opens that file on the server, since that is where the server program is running. Similarly, if a client program executes a system call or changes the working directory it effects the client system. If a server program executes a system call or changes the working directory it effects the server system.
The ACCEPT statement, as a general rule, should not be used in server programs. Server programs are designed to run as invisible "services" that should not require user interaction. You do not want your server program to pause and require user input since it would halt processing and freeze the client program.
Let's take the example of a report program. Most report programs use ACCEPT to enter report parameters, then print the report. If you want to move this type of program to a client/server architecture, you should split the program into two programs. The first should allow entry of the parameters, then call the second and pass it the parameters. The second program creates the report. The first program becomes a client program, the second a server program. The client program has the ACCEPT, the server program does not.
However, in some circumstances you may want to place an ACCEPT statement in a server program during development for debugging purposes. This can be done under the following circumstances.
Under Windows, if the Cobol runtime is configured to display the Cobol window created for each runtime, the ACCEPT statement may be used. When the ACCEPT statement is encountered the server program will stop and wait for user input in its window.
Under Unix, the server Cobol runtime must be started from the command line, not by inetd, in order to use ACCEPT statements. See your release notes for details on starting the server runtime from the command line.
The DISPLAY statement, as a general rule, should not be used in server programs. Server programs are designed to run as invisible "services" and have no need to display information. There is no sense in requiring the server computer to display this information since it is just extra processing overhead.
However, placing DISPLAY statements in server programs will not cause any problems, and may be desirable for debugging purposes.
Under Windows, DISPLAY statements will update the window created for the server runtime. Depending on the Cobol configuration settings this window may or may not be visible.
Under UNIX, DISPLAY statements will have no effect if the runtime was started by inetd. When the Cobol runtime is started by inetd it is not attached to a tty device and cannot display information. However, if the runtime is started from the command line, as described in the release notes, the runtime is attached to a tty device and the DISPLAY statement will update the terminal.
Server programs can call other programs located on the server by using the standard Cobol CALL statement. These calls are not effected in any way by Cobol-RPC.
Server programs can also function as clients and call remote programs located on other servers. The programs must be listed in the [RemotePrograms] section of the cobolrpc.ini file. The calls to other servers are also made by using the standard Cobol CALL statement.
Distributors | Library | Register
Copyright 1996 by England Technical Services, Inc.