In version 1.0 the configuration file, COBOLRPC.INI had to be placed in a specific location. With Windows versions it has to be placed in the Windows directory. Under Unix, it had to be in the /etc directory. This requirement made it difficult to install multiple versions of Cobolrpc.ini on one computer, or to test different configurations.
Version 1.1 also allows the COBOLRPC.INI file to be placed in the working directory. Cobol-RPC will look for the configuration file first in the working directory, then the original location. This makes it possible to install multiple versions or to experiment with different configurations.
Note that with Unix servers the working directory is the home directory of the user assigned to the Cobol-RPC server in the inetd.conf file, not the Cobol-RPC directory. The WorkingDir option in the cobolrpc.ini file can be used to change the working directory, but will not affect the location of the cobolrpc.ini file itself.
In version 1.0 this configuration parameter was used in some implementations to locate remotely called Cobol programs on the server. In version 1.1 the way remotely called programs was changed, eliminating the need for this option. This option is now obsolete in all versions.
Starting with version 1.1 all remotely called Cobol programs on the server are located using the environment variables and search criteria that are inherent to the Cobol being used.
Version 1.0 of Cobol-RPC had different limitations on the number and size of parameters that could be passed in a remote program call depending on the Cobol being used. With version 1.1 the limits have been standardized as follows:
Maximum number of parameters: 20
Maximum size of combined parameters: 60,000 bytes
Version 1.1 adds two special server names that are useful in special ituations. These names can be used in the [RemotePrograms] section or in the DefaultServer entry of the cobolrpc.ini file. If you have a need to use either of these, please contact ETS support for additional information. A special update or license may be required. They are described here so you will be aware of their availability.
The first special name is LOCAL and could be used as follows:
This entry indicates to Cobol-RPC that the program being called is actually on the local machine.
This feature is most valuable for non-Cobol clients that want to call Cobol programs on the client machine. It is also valuable for Cobol implementations that don't support redirected CALL statements when an application is to be executed standalone.
So how is using LOCAL as a server name different from specifying 127.0.0.1 which also identifies the local machine? When Cobol-RPC sees the special name LOCAL it calls the program with less overhead. The Cobol-RPC client starts the Cobol runtime directly eliminating the need for the Cobol-RPC server daemon. It also communicates parameters through shared memory, rather than TCP/IP.
The second special name is CLIENT and could be used as follows:
The CLIENT special name should only be used on a server. When Cobol-RPC sees the CLIENT special name, it will replace it with the address of the client which called the server. This gives the server the ability to make a call back to the client. Since each client has an unique address, there is no other way the cobolrpc.ini file could be configured to make a call back to the client. Of course, Cobol-RPC server software must be installed on the client for the call to be completed.
Distributors | Library | Register
Copyright 1996 by England Technical Services, Inc.