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 four 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.
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:
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.
The third service, provided by ICNETD and the ICLOGS surrogate, is remote logging and file mirroring for ICISAM files. The logging facility, in general, tracks all of the modifications to any ICISAM file that has logging enabled. This allows for robust and quick data recovery procedures in the event of a system crash. The remote logging service takes that concept even further by (1) allowing the log files to be on a different server in the network, and (2) allowing the ICISAM file to be mirrored on another server on the network. This provides the basis for a recovery system that allows for very quick server failover. It also allows for a read-only query server that is reading the up-to-date mirrored files without impacting the performance of the main server.
The fourth 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.