Application Server architecture runs most of the application on the server, deploying only the user interface on the client. Some applications may be programmed to run on the client rather than the server.

Before starting the Application Server, you should ensure that your application runs properly on the server as a stand-alone program. Then the Application Server daemon can be started with the following command:

When a TCP connection is closed the connection may remain in a timeout state for a period of time after the connection is closed (typically known as the TIME_WAIT state or 2MSL wait state). For applications using a well known socket address or port, it may not be possible to bind a socket to the required SocketAddress if there is a connection in the timeout state involving the socket address or port. Use the –force option to achieve it.

Config_file should include the standard configuration, that is the same for every client. See Usage of isCOBOL Client for information about how to use a customized client configuration.

Hostname and port can also be specified in the configuration by setting the following properties:

The following command starts the Application Server on the local PC on the default port 10999.

A correct startup will produce an output similar to this:

On Unix/Linux machines the iscserver command requires either ISCOBOL_JDK_ROOT or ISCOBOL_JRE_ROOT along with ISCOBOL environment variables set in order locate the Java and isCOBOL installation directories and start correctly. If you installed the product using the wizard setup procedure, you can rely on the following alternate command:

This script takes care of setting the necessary environment variables and starts the isCOBOL Server with a preset configuration found in the file $ISCOBOL/etc/appserver.properties.

On client machines, the following command should be used:

When the client machine is Windows, the following command can also be used:

The difference is that iscclient keeps the console busy while isclient runs in a separate task.

The isclient command output is stored in two files, isclient_out.log and isclient_err.log, located in the isCOBOL bin directory. Ensure that the bin directory of isCOBOL has write permissions.

Host name, port, and a remote configuration file can also be set in the configuration file, as shown below.

See Usage of isCOBOL Client for all the possible options provided by iscclient.

In the thin client architecture every client that connects to the Application Server becomes a thread in the JVM process associated to the Application Server and is assigned with a uniqure progressive identificator number (thread id) in the range between 1 and 2147483647.

The following Java property can be set to avoid unexpected lock errors when two clients open the same relative/sequential file having Lock Mode Automatic:

If the hostname parameter is not specified neither on the command line nor among configuration properties, then the isCOBOL Server will accept connections from all the local addresses. The following table summarizes the connection result in different combinations of isCOBOL Client and isCOBOL Server hostname parameter values:

Note - The above information is accurate as long as localhost is mapped to the IP address 127.0.0.1 in the system.