RM/Panels Client/Server with Cobol-RPC


Overview
RM/PANELS in a Thin Client Architecture
How RM/PANELS and Cobol-RPC work together
Details of Configuration
Networking Options
Special Considerations

Overview

For the last year ETS has been marketing a product called Cobol-RPC. This product makes it easy to implement distributed processing in COBOL by allowing an application to CALL a COBOL program on a remote computer. This product has been used to build both client/server and other more sophisticated types of distributed applications.

Most Cobol-RPC users are creating "fat client" applications, with user interface logic executing on the client and business logic executing on the server. However, some Cobol-RPC users are using the product in a "thin client" architecture, where the application logic executes entirely on the server and the user-interface is presented graphically on a Windows client. Sinc's FlexGen Frontier product is an example of this. The appeal of this approach is that it allows a full-featured graphical user interface without requiring the re-engineering of the software into a multi-tier architecture. This type of "thin client" architecture is very similar to that of a "network computer".

Cobol-RPC can be used with RM/PANELS in a thin client architecture. Together they can provide a full graphical user interface for an application running on a Unix server. This does not require changes to RM/COBOL, RM/PANELS, or the user's application. Cobol-RPC simply allows the RM/PANELS runtime to run on the Windows machine, while the rest of the application runs on the server.

This ability to redeploy an existing Unix based RM/PANELS application in a client/server architecture with a graphical user interface is a tremendous benefit to users and leverages their investment in RM/COBOL and RM/PANELS development.

RM/PANELS in a Thin Client Architecture

Unix RM/PANELS applications are currently deployed in the following architecture:

All application logic is executed on the Unix machine. The user interface is presented to the user on TTY terminal devices or terminal emulators. Processing in this architecture is fast because the logic executes on the server where data is locally available. This architecture is also easy to maintain, since all application programs are located in a single location. Unfortunately, the tty devices cannot provide a graphical user-interface.

With Cobol-RPC, RM/PANELS applications can be deployed in the following architecture:

This architecture maintains the advantages of the previous architecture; speed and ease of maintenance. What it adds is a graphical user-interface. The Windows client simply needs a TCP/IP connection to the Unix machine rather than a tty connection. This can be done over existing serial cables or ethernet.

How RM/PANELS and Cobol-RPC work together

Let's take a look at how this thin client architecture works with RM/PANELS and Cobol-RPC.

The process starts on the client, where the user double clicks on an icon associated with a generic Cobol-RPC program, THINCLNT.EXE. (Any icon may be used for this program) This program makes a TCP/IP connection to the Unix machine.

When the Unix machine receives the connection it starts the user's application. This is handled by the standard inetd process. The application executes normally until it is ready to display a panel.

A panel display is accomplished by calling the panels runtime program, runpan2.cob. When the Unix program calls runpan2.cob, Cobol-RPC intercepts the call and reroutes it and it's parameters back to the same Windows machine that made the initial connection. Runpan2.cob is then executed on the client, using the same parameters it would have received on Unix. Runpan2.cob opens the panel library on the Windows machine (or on a mapped network drive) and retrieves the panel definition. Then, since runpan2.cob is running on Windows it acts as though it were called by a Windows program and displays the panel in a graphical form.

When runpan2.cob completes its processing, Cobol-RPC routes the return parameter values back to the calling Unix program. The beauty of the situation is that the Unix application feels as though it is calling runpan2.cob ON THE UNIX MACHINE and runpan2.cob feels as though it were called BY THE WINDOWS MACHINE. Everyone feels right at home.

Details of Configuration

Here is a detailed breakdown of how the components of this architecture are deployed:

On the Windows Clients

RM/COBOL runtime for Windows
Cobol-RPC Thin Client for Windows
*runpan2.cob
*Panel Library(s)

On the Unix Server

User's RM/PANELS application
RM/COBOL runtime for Unix
Cobol-RPC for Unix
Cobol-RPC configuration file

*Note that these files do not have to physically reside on the client. They must be available to the RM/COBOL Windows runtime so they could be accessed through RM/InfoExpress or some other network mapping scheme. Locating these files on the server would eliminate the need to update clients when they are changed. This is only significant for the Panel Library(s).

Networking Options

The Windows clients can be networked to the Unix server via any network with TCP/IP support including serial and ethernet. A serial TCP/IP connection would have the advantage of utilizing existing cable, while an ethernet connection would be much faster.

Special Considerations

Some RM/PANELS applications also use DISPLAY/ACCEPT statements. This is not compatible with the new architecture. Since the DISPLAY/ACCEPT statement is executed by a UNIX program, the RM/COBOL runtime will attempt to execute the DISPLAY/ACCEPT operation on the Unix machine. This will not have the desired effect.

The login process is slightly different. A user id and password will be required to make the initial TCP/IP connection to the Unix machine and can be administered through traditional means. However, when the thin client startup program on the Windows machine (THINCLNT.EXE) makes the connection to the Unix machine to start the application, the user name associated with the process will be the user specified in the inetd.conf entry. Some applications may need to set the user associated with the process to a specific user. This can be done through a supplemental ChangeUser function supplied by ETS.


Home | About | Products | Contact
Distributors | Library | Register

Copyright 1997 by England Technical Services, Inc. All Rights Reserved