Client/Server

Client/Server support is provided via the ICOBOL Network Daemon (ICNETD), which runs on the Linux or Windows based server to process client service requests. There are currently three different types of client requests, which are described in the following sections. The ICNETD process determines the type of client when the client first connects and it starts an appropriate service process (surrogate) to perform the client's requests for the duration of its session.

Requests are managed between the clients and the server via a TCP/IP-based private protocol that encodes all data between the client and the server, so your information is secure. Also, because the transport is via standard TCP/IP, the clients can connect to a server via local or wide area networks, through secure VPN tunnels, and even over the internet. It is thus possible to install a client/server solution supporting a large number of different physical locations.

The licensing for the client/server products is determined by the type of client and the number of simultaneous client sessions that are required. All licensing is handled by the server, so there are no client licenses to install. Please visit the pricing page for more details.

Client/Server File Access

Shared file access support for Interactive COBOL applications in a client/server environment is provided via the ICNETD server and the ICIOS surrogate. The surrogate provides support not only for ICISAM-based INDEXED and RELATIVE files, but also for SEQUENTIAL files, including special files like printer queues.

Client/Server File Access is required for environments where files are being shared among multiple Linux machines or a mixture of Linux and Windows machines. It is not reuired for sharing files in a Windows-only environment, but it has the potential to improve performance dramatically, depending on the nature of the file access activity.

Currently, the following components can operate as File Access clients:

• The ICOBOL Runtime System itself
• The ODBC Driver product

ThinClient Runtime

A second service, provided by ICNETD and the ICRUNRS surrogate, is the ThinClient Runtime, which is a special version of the standard runtime system that communicates all user-interface operations to the corresponding client component. The client component, called icrunrc, provides both a character-mode interface and a GUI-mode interface (using sp2) from an application running on the server. Since the one client supports both types of interface, an application can have a mixture of character screens and GUI screens, allowing GUI elements to be introduced into an old character-mode application in phases. The client side is very compact because it simply provides the user interface to the application running on the server. Note that non-Windows based servers can be used for Windows-based GUI clients.

There are some differences between the ThinClient solutions in ICOBOL 4 & 5 and ICOBOL 3. The ICOBOL 4 & 5 private protocol encodes all data, whereas the ICOBOL 3 protocol did not. In addition, the ICOBOL 4 & 5 client also has an automatic reconnection facility (except when using HP-UX for either the client or the server). The ICOBOL 4 & 5 client handles both character-mode and GUI-mode interfaces that can handle a mixed-mode application; unlike ICOBOL 3, which had separate character-mode and GUI-mode clients, requiring an all-or-nothing conversion to a GUI interface before taking advantage of thinclients.

Remote ISQL Processing

The third service, provided by ICNETD and the ICSQLS surrogate, is remote processing of integrated SQL (ISQL) requests from the runtime system. Normally, the runtime system processes ISQL requests locally by connecting to a local ODBC driver. In some cases, this local ODBC driver is actually using files located on another server. For example, this can be the case when using the ICOBOL ODBC driver configured to access the ICISAM files on another server using ICOBOL Client/Server File Access. By using the Remote ISQL Processing option, the connection to the ODBC driver is made on the server machine. In many cases using this option will improve processing performance. In some cases, it may save the expense of having to purchase a cross-platform, networked ODBC driver from a database vendor.