Application Versioning in UNIX and Linux IT › How Application Versioning Works

How Application Versioning Works

A pair of header files are used to represent versioning information that is compiled and linked into CA Gen generated applications. These files are application.h and *_buildver.h.

Application.h contains a set of #defines that refer to information displayed when using the $IEFH/make/version_info.ksh script on the built application files. The customer can edit the #defines in this file to customize an application's version information. The following #define values are customizable in the application.h file:

PRODUCT_VERSION - Provides a unique product version number
PRODUCT_NAME - Provides a unique product name

*_buildver.h is a generated header file that contains only 1 #define:

#define BUILDVERS "xxxx"

The BUILDVERS #define refers to the currently incremented build version of the customer's application. This build version is incremented each time the application is built. There is one version of this header file for each load module, cascade and operations library built for a given CA Gen generated application. If needed, the BUILDVERS #define can be changed by the customer to provide an alternate starting build number for the application.

During the application build, the build script checks for application.h in the application's build directory. If they do not exist, it is copied from $IEFH/include. Otherwise, it uses the existing copy that may or may not have been customized in the application’s build directory. Also, if the *_buildver.h file is not present for the load module, cascade, or operations library being built, a new version of the file is built with an initial BUILDVERS value of “00001”.

The shell script applno.ksh, executed during an application build, increments the application's build number in the application's *_buildver.h file. The information in application.h and *_buildver.h is compiled into the generated version stub files gversion.c (for load modules), oversion.c (for operations libraries), or tversion.c (for RI Triggers). The resultant object is then linked into the application or library being built.

The object file created contains a unique string which is identified by executing the $IEFH/make/version_info.ksh script on the executable or library created. When it creates an operations library that uses other operations libraries, the awk script, version.awk, executes to collect the set of unique strings from other operations libraries to be linked into the built operations library. Executing the $IEFH/make/version_info.ksh script on the built operations library will then list other operations libraries that may have been linked into the just built operations library.

Repeated application builds result in an updated build number reflected when executing the $IEFH/make/version_info.ksh script on the rebuilt executable or library.

Using version_info.ksh

The shell script version_info.ksh is delivered in $IEFH/make and is used to display versioning information for all CA Gen libraries that are linked into a CA Gen generated application. The version_info.ksh script is invoked as follows:

$IEFH/make/version_info.ksh  <model directory> <load module>
Where:	<model_directory>	is the fully qualified directory where the application was built

<load module>		is the name of the load module that you are obtaining version information for

This script can be used to obtain versioning information on any application or library that was built with the Build Tool, including load modules, cascade libraries and operations libraries.

Applications and libraries evaluated can be built statically (archived) or dynamically (shared).

The following version information is displayed for each CA Gen library listed: