Automatic Client update

Unless the -noupdate option appears on the client command line or the iscobol.as.clientupdate.site is not set in the server side configuration , each time a thin client is launched, it looks for updates before starting the COBOL program.

The update process is described below:

1.	The isCOBOL Server sends to the following information to the thin client:

o

URL of the Update Server as specified by iscobol.as.clientupdate.site in the server side configuration. This URL can point either to a third party HTTP server or to a a isCOBOL Server started with the -hs option, as described in isCOBOL Server as HTTP server. Such server is configured by a file named swupdater.properties where the following entries must be provided:

Entry	Meaning
swupdater.version.iscobol	Build number of the jar libraries.
swupdater.version.iscobolNative	Build number of the native libraries. It should match with the build number of the jar libraries. See Configuring different repositories for native libraries for details about platform and bitness.
swupdater.lib.iscobol	Folder or zip file containing the jar libraries.
swupdater.lib.iscobolNative	Folder or zip file containing the native libraries. See Configuring different repositories for native libraries for details about platform and bitness.

See the Update Facility Server configuration for more information about the HTTP server setup.

o	Current client build number as specified by iscobol.as.clientupdate.version in the server side configuration. If this property is omitted, then the thin client will use the build number of its jar libraries.

2.	The thin client runs the Update Facility to connect to the Update Server and check for updates. It uses the following default configuration:

Default configuration for Windows Clients	Default configuration for Linux/Mac OS Clients
swupdater.version.iscobol=<clientBuildNumber> swupdater.version.iscobolNative=<clientBuildNumber> swupdater.directory.iscobol=<isCOBOLInstallDir>/lib swupdater.directory.iscobolNative=<isCOBOLInstallDir>/bin	swupdater.version.iscobol=<clientBuildNumber> swupdater.version.iscobolNative=<clientBuildNumber> swupdater.directory.iscobol=<isCOBOLInstallDir>/lib swupdater.directory.iscobolNative=<isCOBOLInstallDir>/native/lib

Note - It is possible to customize the above configuration by putting a isupdater.properties configuration file in the client side Classpath. See Client Configuration (isupdater.properties) for more information about the possible configuration entries.

a.	If the server is down or no update is necessary, the thin client execution continues normally

b.	If some updates were executed, the thin client is automatically restarted with the -noupdate option

The need of updating is determined by comparing the build numbers specified by the swupdater.version properties used by the client with the build numbers specified by the swupdater.version properties in the server side swupdater.properties file.

Configuring different repositories for native libraries

The Update Server may need to provide different native libraries to different clients depending on the client operating system and architecture. This is achieved by extending the iscobol.version.iscobolNative and iscobol.lib.iscobolNative property names as demonstrated below.

In the snippet below we show how to fill the swupdater.properties file for a Linux server that needs to update Windows clients both 32 and 64 bit, having all the necessary items stored in the /repository1 folder on the HTTP server:

swupdater.version.iscobol=875.6 swupdater.lib.iscobol=/repository1/lib swupdater.version.iscobolNative=875.6 swupdater.lib.win.32.iscobolNative=/repository1/native/win32/lib swupdater.lib.win.64.iscobolNative=/repository1/native/win64/lib

We notice that the 'iscobol' package is the same for all operating systems and architectures, instead the 'iscobolNative' packages are specified with different directories, one for each possible operating system and architecture combination.

Note - It is possible also to specify only the operating system, e.g.

swupdater.lib.win.iscobolNativeWin=<directory>

For example, if the client is Windows 64 bit, it checks if there is a library specified for Windows 64 bit; if not, it checks if there is a library specified for Windows; if not, then it requires the generic library.

No action is required client side. The client receives from the server the list of the available libraries and automatically detects its operating system and architecture, so it downloads the proper libraries.