Building embedded SQL applications using the sample build script

The files used to demonstrate building sample programs are called script files on UNIX and Linux® operating systems, and batch files on Windows operating systems. These files are collectively called build files and contain the recommended compile and link commands for supported platform compilers.

Build files are provided by Db2® for host languages pertaining to supported platforms. The build files are available in the same directory to where the samples for that language are contained. The following table lists the different types of build files for building different types of programs. These build files, unless otherwise indicated, are for supported languages on all supported platforms. The build files have the .bat (batch) extension on Windows, which is not included in the table. There is no extension for UNIX platforms.

Table 1. Db2 build files
Build file	Types of programs built
bldapp	Application programs
bldrtn	Routines (stored procedures and UDFs)
bldmc	C/C++ multi-connection applications
bldmt	C/C++ multi-threaded applications
bldcli	CLI client applications for SQL procedures in the sqlpl samples sub-directory.

Note: By default the bldapp sample scripts for building executables from source code will build 64-bit executables.

The following table lists the build files by platform and programming language, and the directories where they are located. In the online documentation, the build file names are hot-linked to the source files in HTML. The user can also access the text files in the appropriate samples directories.

Table 2. Build files by language and platform
Platform —> Language	AIX®	HP-UX	Linux	Solaris	Windows
C samples/c	`bldapp` `bldrtn` `bldmt` `bldmc`	`bldapp` `bldrtn` `bldmt` `bldmc`	`bldapp` `bldrtn` `bldmt` `bldmc`	`bldapp` `bldrtn` `bldmt` `bldmc`	`bldapp.bat` `bldrtn.bat` `bldmt.bat` `bldmc.bat`
C++ samples/cpp	`bldapp` `bldrtn` `bldmt` `bldmc`	`bldapp` `bldrtn` `bldmt` `bldmc`	`bldapp` `bldrtn` `bldmt` `bldmc`	`bldapp` `bldrtn` `bldmt` `bldmc`	`bldapp.bat` `bldrtn.bat` `bldmt.bat` `bldmc.bat`
IBM® COBOL samples/cobol	`bldapp` `bldrtn`	`n/a`	`n/a`	`n/a`	`bldapp.bat` `bldrtn.bat`
Micro Focus COBOL samples/cobol_mf	`bldapp` `\bldrtn`	`bldapp` `bldrtn`	`bldapp` `bldrtn`	`bldapp` `bldrtn`	`bldapp.bat` `bldrtn.bat`

The build files are used in the documentation for building applications and routines because they demonstrate very clearly the compile and link options that Db2 recommends for the supported compilers. There are generally many other compile and link options available, and users are free to experiment with them. See your compiler documentation for all the compile and link options provided. Besides building the sample programs, developers can also build their own programs with the build files. The sample programs can be used as templates that can be modified by users to assist in their application development.

Conveniently, the build files are designed to build a source file with any file name allowed by the compiler. This is unlike the makefiles, where the program names are hardcoded into the file. The makefiles access the build files for compiling and linking the programs they make. The build files use the $1 variable on UNIX and Linux and the %1 variable on Windows operating systems to substitute internally for the program name. Incremented numbers for these variable names substitute for other arguments that might be required.

The build files allow for quick and easy experimentation, as each one is suited to a specific kind of program-building, such as stand-alone applications, routines (stored procedures and UDFs) or more specialized program types such as multi-connection or multi-threaded programs. Each type of build file is provided wherever the specific kind of program it is designed for is supported by the compiler.

The object and executable files produced by a build file are automatically overwritten each time a program is built, even if the source file is not modified. This is not the case when using a makefile. It means a developer can rebuild an existing program without having to delete previous object and executable files, or modifying the source.

The build files contain a default setting for the sample database. If the user is accessing another database, they can simply supply another parameter to override the default. If they are using the other database consistently, they could hardcode this database name, replacing sample, within the build file itself.

For embedded SQL programs, except when using the IBM COBOL precompiler on Windows, the build files call another file, embprep, that contains the precompile and bind steps for embedded SQL programs. These steps might require the optional parameters for user ID and password, depending on where the embedded SQL program is being built.

Finally, the build files can be modified by the developer for his or her convenience. Besides changing the database name in the build file (explained previously) the developer can easily hardcode other parameters within the file, change compile and link options, or change the default Db2 instance path. The simple, straightforward, and specific nature of the build files makes tailoring them to your needs an easy task.