Installing IBM DB2 for Linux, UNIX, and Windows transparently with your application
Unlike standard DB2® for Linux, UNIX, and Windows setup utilities, a DB2 response file installation, also known as a silent installation, lets you install DB2 without user input. This is useful not only for large-scale deployments of DB2, but also for embedding the DB2 installation process inside your own application installation. The response file installation is one of the ways DB2 provides a complete solution for your embedded database needs.
A DB2 response file installation is a background installation process that you can embed into an existing application installer and is transparent to end users. It is performed by DB2 setup utilities with user-generated response files. The response files are ASCII text files that contain setup and configuration information. They can be generated using DB2 utilities or by manual editing.
This article describes the complete DB2 response file installation process on Linux, UNIX, and Windows platforms. Response file generation and installation are described in detail, along with special considerations for embedding the DB2 installation process into your own application installer.
When embedding a DB2 installation inside your own installer, it is sometimes desirable to prune the DB2 install image. The standard DB2 image contains a lot of extras such as GUI tools, documentation in several languages, and application development support. These extras inflate your installation program footprint unnecessarily. This article also describes how to safely prune a DB2 installation image.
Generating a response file
The first step involved in the silent installation process is to generate a response file. When installing DB2 using the interactive GUI setup utility, you are prompted to make installation choices and provide necessary configuration data before installation takes place. Response files simply contain these installation choices and configuration data.
There are three methods you can use to generate a response file:
- Using the DB2 Setup wizard
- Using the DB2 response file generator utility (Windows only)
- Creating a response file manually
As previously stated, response files are simply ASCII text files. Listing 1 shows a snippet of sample of a response file.
Listing 1. Sample snippet of a response file
PROD=WORKGROUP_SERVER_EDITION LIC_AGREEMENT=ACCEPT FILE=C:\Program Files\IBM\SQLLIB_03\ INSTALL_TYPE=TYPICAL LANG=EN ... INSTANCE=DB2 DB2.NAME=DB2_03 DEFAULT_INSTANCE=DB2 DB2.SVCENAME=db2c_DB2_03 DB2.DB2COMM=TCPIP DB2.PORT_NUMBER=50003 ... DB2_COPY_NAME=DB2COPY3 DEFAULT_COPY=NO DEFAULT_CLIENT_INTERFACE_COPY=NO ...
You can find a complete sample response file on your DB2 installation DVD in the following location:
- db2/<platform>/samples (where platform represents the appropriate Operating System)
The response file is named db2<edition_abbreviation>.rsp . For example, it is db2wse.rsp for DB2 Workgroup Server Edition. Table 1 shows several commonly used edition abbreviations and their descriptions.
Table 1. Commonly used DB2 product edition abbreviations
Abbreviation | Product Edition |
---|---|
ese | DB2 Enterprise Server Edition |
wse | DB2 Workgroup Server Edition |
exp | DB2 Express Edition |
pe | DB2 Personal Edition |
conee | DB2 Connect Enterprise Edition |
For a brief description of some of the DB2 response file keywords, see Manually generating a response file.
Using the DB2 Setup wizard
The DB2 Setup wizard is the GUI installation utility available on supported platforms. It is the program that you normally run interactively when you install DB2. Instead of, or in addition to, installing the product, you can also save all of your choices in a response file for later use.
If you have never used the DB2 Setup wizard before and need to locate it, you can find it as follows:
- For Microsoft® Windows, the executable is called setup.exe and is located at the root directory of the installation DVD or image.
- For Linux and UNIX platforms, the executable is called db2setup and is located at the root directory of the installation DVD or image.
Once the DB2 Setup wizard is launched, you can choose any of the installation types as shown in Figure 1.
Figure 1. Choosing the installation type

After you choose the installation type and proceed to the next screen in the wizard (shown in Figure 2), you are presented with the option of saving the installation choices in a response file, performing the installation, or both. You can also specify the location (path) and file name for the response file.
Figure 2. Creating a response file using the DB2 setup wizard

After this step, continue to work through the installation wizard by specifying any additional configuration choices. Once you click Finish on the final screen, all your selections will be saved in the response file you specified. Note that if you are installing in a partitioned environment, that is, an environment using the Database Partitioning Feature (DPF), then two response files are created; one for the instance-owning computer and a second one for the other participating computers.
In a DPF environment, multiple servers are clustered together to form a single logical instance and database. From the application's point of view, it looks like a non-partitioned database, but under the covers, the database gets partitioned to all the machines in the cluster. One of the partitions or servers hosts DB2's metadata, also known as DB2 catalog data. This partition becomes instance owning partition and generally does not contain much user data. Other partitions become participating partitions or servers and these contain the user data. The name of the second response file generated is based on the response file name specified.
Using the DB2 response file generator
The DB2 response file generator utility is available on Windows platforms only. The idea is to create a master installation first and then use the response file generator to create a response file that will install the same components and use the configuration as the master. The utility can also generate instance profiles to create and configure a DB2 instance. Figure 3 shows the syntax for the response file generator utility, called db2rspgn.
Figure 3. Syntax for db2rspgn utility

By default, db2rspgn generates profiles for all instances on the master
installation along with the response file. You can choose not to create
profiles for the control server instance by specifying the
-nocltsv
option. You can also specify
individual instances to create profiles for. Profile files are put in the
same directory as the generated response file.
You will have to do some minor editing on the generated response files before they are usable:
- Manually modify the file to accept the license agreement.
- Enter the user ID and password for the target system.
Creating response files manually
Since response files are simply ASCII text files, you can create them manually. You can choose to modify the sample response files provided with the DB2 installation image or type it from scratch. This method requires a solid understanding of the response file structure and keywords. Fortunately, the sample response files are well commented and self-explanatory.
Table 2 provides brief descriptions of some of the more common keywords that you might specify in the response file:
Table 2. Commonly used response file keywords
Keyword | Description |
---|---|
PROD | Specifies the product that you want to install. For example, you can choose to install DB2 Workgroup Edition or other editions, or to install the DB2 client only. |
FILE | Specifies the destination directory for a DB2 product. For non-root installations (available on Linux and UNIX only), this parameter should be omitted. |
INSTALL_TYPE | Specifies the type of installation: COMPACT, TYPICAL or CUSTOM. |
COMP | Specifies your language option. |
REBOOT | Specifies whether to restart the Windows system when the installation has completed. |
KILL_PROCESSES | Specifies if the installation will terminate the currently running DB2 processes without prompt (for Windows only). |
DB2_COPY_NAME | Specifies the DB2 copy name. Starting DB2 V9.1, you can install multiple copies of DB2 on a machine. Each installation has a copy name, in order to differentiate between the multiple installations. |
DEFAULT_COPY | Indicates if current install should become the default copy. |
Other keywords exist to specify DB2 Administration Server settings, DB2 Instance settings, and Database settings. For a complete list of keywords, detailed description and usage information, see the sample response file on your installation DVD or the DB2 Information Center.
Using response files for unattended installation
This section describes:
The unattended installation process
After you generate a response file, unattended (silent) installation is straightforward. You use the same executable that you would use in the GUI installation; however, you must also provide the proper response file name. You can also specify other options such as log file path and name.
Listing 2 shows the syntax for the Setup utility on Windows. Only the response file name with the full path is mandatory for a response file installation.
Listing 2. Syntax for setup utility on Windows platforms
setup [/f] [/i <language>] [/l <log file>] [/u <response file>] [/t <trace file>] /? - generates this usage message /f - forces any db2 processes to stop before installing /i - two letter code for the preferred language /l - full path and name of the log file /u - full path and name of the response file /t - creates a file with install trace information
On Linux and supported UNIX platforms, use the db2setup syntax shown in Listing 3.
Listing 3. Syntax for the db2setup utility on Linux and UNIX platforms
>>-db2setup--+---------------+--+---------------+---------------> '- -i--language-' '- -l--log_file-' >--+-----------------+--+--------------------+--+-----+-------->< '- -t--trace_file-' '- -r--response_file-' +- -?-+ '- -h-'
The unattended installation process runs in the background. No DB2 installation GUI screens appear. When embedded with your own installer, the DB2 installation appears to be part of your installation process. Upon completion, the DB2 installation process returns a return code to your program. You can choose to monitor the return code in your installer. Table 3 and Table 5 contain the primary return codes for Linux, UNIX, and Windows. The primary return codes are the most commonly received and you should code to handle them. There are also secondary return codes, which are less commonly seen. These codes are in Table 4 and Table 6. These four tables can also be found in the DB2 Information Center.
Table 3. Primary response file installation return codes on Windows
Return Code | Description |
---|---|
0 | The action completed successfully. |
1 | The action returns a warning. |
1603 | A fatal error occurred during the installation. |
3010 | Install was successful; however, a reboot is required to complete the installation. |
0 | The action completed successfully. |
0 | The action completed successfully. |
0 | The action completed successfully. |
0 | The action completed successfully. |
Table 4. Secondary response file installation return codes on Windows
Return Code | Description |
---|---|
3 | The path was not found. |
5 | Access was denied. |
10 | An environment error occurred. |
13 | The data is invalid. |
87 | One of the parameters was invalid. |
1602 | The installation was cancelled by the user. |
1610 | The configuration data is corrupt. Contact your support personnel. |
1612 | The installation source for this product is not available. Verify that the source exists and that you can access it. |
1618 | Another installation is already in progress. Complete that installation first before proceeding with this installation. |
1622 | There was an error opening the installation log file. Verify that the specified log file location exists and that it is writable. |
1632 | The Temp folder is either full or inaccessible. Verify that the Temp folder exists and that you can write to it. |
1633 | This installation package is not supported on this platform. |
1638 | Another version of this product is already installed. Installation of this version cannot continue. |
1639 | Invalid command line argument. |
Table 5. Primary response file installation return codes on Linux and UNIX
Return Code | Description |
---|---|
0 | The action completed successfully. |
1 | The action returns a warning. |
67 | A fatal error occurred during the installation. |
Table 6. Secondary response file installation return codes on Linux and UNIX
Return Code | Description |
---|---|
3 | The path was not found. |
5 | Access was denied. |
10 | An environment error occurred. |
13 | The data is invalid. |
16 | The DAS creation failed. |
17 | The instance creation failed. |
18 | The database creation failed. |
19 | The fix pack image is at a lower level than the installed product. |
20 | The fix pack image is at the same level as the installed product. There is nothing to update. |
21 | There are no DB2 products installed at the selected location. There is nothing to update. |
22 | To update an already installed DB2 product, use the installFixPack command instead of the db2setup command. |
66 | The installation was cancelled by the user. |
74 | The configuration data is corrupt. Contact your support personnel. |
76 | The installation source for this product is not available. Verify that the source exists and that you can access it. |
82 | Another installation is already in progress. Complete that installation first before proceeding with this installation. |
86 | There was an error opening the installation log file. Verify that the specified log file location exists and that it is writable. |
87 | One of the parameters was invalid. |
96 | The temp folder is either full or inaccessible. Verify that the Temp folder exists and that you can write to it. |
97 | This installation package is not supported on this platform. |
102 | Another version of this product is already installed. Installation of this version cannot continue. |
103 | Invalid command line argument. |
143 | The system does not have enough free space to continue with the installation. |
Logging the installation
The path and the name of the log file are optional parameters to the DB2 setup program. If you do not specify the name and the path of the log file, default log files are created for you in the default directory:
- On Windows, the default file name is
DB2-ProductAbbreviation-DateTime.log For example:
DB2-ESE-Wed Jun 21 11_59_37 2006.log
. The default location for the installation log is the My Documents\DB2LOG\ directory under the user account which the DB2 installation was performed with. - On Linux and UNIX platforms, the default file name is db2setup.log is found in the /tmp directory. You may also find some other DB2 generated files in that directory. The db2setup.his log file maintains a history of current and past installations. The db2setup.err log file contains all the error entries. For non-root installations, the default log file is /tmp/db2setup_userID.log, where userID represents the user ID that owns the non-root installation.
Tracing the installation
The path and the name of a trace file are also optional parameters to DB2 setup program. Trace files contain service information for IBM support and are not really meant for users. You can safely remove them after a successful installation. When you do choose to create the trace file, the DB2 installation log files are generated in verbose mode, which means that much more detailed information is generated in the log files.
Special considerations
If you intend to use a response file for deploying DB2 on many machines or for embedding it in an application installer, make sure you check prerequisites, ensure that no DB2 processes are running, and have a plan for handling a failed installation.
Checking prerequisites
Like the DB2 GUI setup wizard does, make sure that all prerequisites are met in your own installation script before starting the DB2 response file installation process. Prerequisites include both user privileges and system configuration. DB2 installation prerequisites are well documented in both the DB2 documentation and the readme files on the installation DVDs. If you are performing a non-root installation(Linux/UNIX only), then there are further requirements and restrictions that apply. See the DB2 Information Center for more details.
Killing DB2 processes before starting an installation
A DB2 installation cannot occur when there are active DB2 processes
running. On Windows only, you could use either the
KILL_PROCESSES
keyword in the response file or
the /F
option on with the
setup
command to kill active DB2 processes.
However, killing DB2 processes can cause loss of data. You might want to
issue db2stop
on each instance instead. See the
DB2 Information Center
for complete syntax before using the db2stop command.
User program intervention
User program intervention is not possible during the DB2 response file installation. After the installation process has started, it will run on its own. All your installation program must do is monitor the final return code.
Failed installation
When the installation fails, the DB2 installation process normally cleans up any partially installed component. Your own installation program could parse and check the log files or check the return codes to pinpoint the problem. If the problems can be remedied, you can try to install DB2 again.
Creating and setting up databases
After you have DB2 installed and configured, the next logical steps are:
- Create your database.
- Create your database objects, such as tables, views, triggers, functions and procedures.
- Populate your tables with data.
While these tasks are beyond the scope of this article, they are discussed here briefly for completeness. How you create and set up your databases largely depends on the programming languages you use. You can do this setup with scripts, or with programs written in C, JavaTM and many other programming languages of your choice. You can even do it with a combination of scripts and programs. The simplest way to create a database is to manually add a database section in the response file. A database will be created for you at the end of the installation. Listing 4 shows a snippet of a response file that creates a database called MY_DB1 in the DB2INST1 instance.
Listing 4. Sample database section in response file
... DATABASE = MY_DB MY_DB.INSTANCE = DB2INST1 MY_DB.DATABASE_NAME = MY_DB1 MY_DB.LOCATION = LOCAL MY_DB.ALIAS = MY_DB1 MY_DB.USERNAME = username MY_DB.PASSWORD = password ...
You can also create databases with scripts or with DB2 native C APIs. After the database is created, the database objects can be created and tables can be loaded. Again you can use many programming languages and their corresponding APIs for loading data, such as C and ODBC/CLI, or Java and JDBC. If you have a large amount of data to load, consider using the DB2 IMPORT or LOAD utilities. For syntax and usage of IMPORT and LOAD, see the DB2 Information Center.
Uninstalling DB2
You can also embed DB2 uninstallation in your own uninstallation program. The following sections describe the uninstall process step-by-step.
Uninstalling DB2 on Windows
On Windows systems, you need to perform the following steps, in this order:
- Drop all databases by entering the following command:
DROP DATABASE database-alias
- Disconnect all applications by entering the following command:
FORCE APPLICATION ALL
- Stop all DB2 processes and services by entering the following
commands:
db2stop
anddb2admin stop
- Remove DB2 product. To do this programmatically, use the
db2unins
command. For example, to uninstall DB2 Enterprise Server Edition(ESE), you would use:db2unins -p "ESE"
To uninstall DB2 silently using a response file, you would use:db2unins -u <response file>
For more information about the above commands, refer to the DB2 Information Center.
Uninstalling DB2 on Linux and UNIX
On Linux and UNIX, you need to perform the following steps, in this order:
- Drop all databases by entering the following
command:
DROP DATABASE database_alias.
- Stop the DB2 Administration Server by logging in as the DB2
administration server owner and issuing the
db2admin stop
command. - Stop all DB2 instances by repeating the following steps for each
instance you created:
- Log in as the instance owner.
- Severe all database connections by entering the
FORCE APPLICATION ALL
command. - Stop the DB2 database manager by entering the
db2stop
command.
- Remove the Administration Server:
- Log in as root.
- Issue the
command:
/opt/ibm/db2/V9.5/instance/dasdrop
.
- Remove DB2 instances by repeating the following steps for each
instance you created:
- Log in as root.
- Issue the
/opt/ibm/db2/V9.5/instance/db2idrop InstanceName
command. - Remove the instance owner's user ID and group if you created them during installation and if they are used only by your program.
- Remove DB2. You must have root authority for uninstalling.
- Use the
db2_deinstall
command in the root directory of the DB2 DVD or image.
- Use the
The commands given in the steps above are the same for all Linux and UNIX platforms. However, the install paths vary depending on the operating system. In the previous example, we have shown installation paths for Linux. For more information on above installation paths and DB2 commands, refer to the DB2 Information Center.
Pruning DB2 install images
It can be useful to prune DB2 install image to remove unecessary components
for large-scale deployments of the DB2 product, as well as for embedding
DB2 within an application. Pruning can give you a smaller installation
image footprint, that is faster to transfer and install. After pruning the
install image, it is highly recomended that you thoroughly test the pruned
image to make sure that no required items have been taken out and all the
features you need are available. If you choose to prune the install image,
you should choose the CUSTOM
installation type,
as shown in Figure 1. It allows you to uncheck any
components that you have removed from the installation image. If you
choose a TYPICAL
or
COMPACT
installation with a pruned install
image, you may get an eror message about missing files.
Pruning a DB2 install image on Windows
The db2iprune utility is available on Windows only to automate the process of pruning the install image. It removes the Windows cabinet(.cab) files associated with those features as well as any languages that are marked for pruning based on the pruning input file. There is a sample input file (.prn file) available on the installation DVD at db2\Windows\utilities\db2iprune. The input file, which resembles a response file, allows you to specify which features and languages you would like to remove from the installation image. The result is a new, smaller DB2 installation image that can be installed using the regular DB2 installation methods. There is a two step process to prune the DB2 installation image on Windows:
- Open the sample input .prn file provided in the installation image.
Uncomment the features or languages that you want to remove by
removing the asterik(*). Input file contains three keywords:
- PROD specifies the product to be installed
- LANG specifies the languages
- COMP specifies the features
- Once you have a customized .prn file ready you can run db2iprune
command. Syntax for db2iprune command is as follows:
db2iprune -r input_file_path -p root_directory_path -o destination_directory_path
where "-r" specifies the input .prn file, "-p" specifies the location of source image and "-o" specifies the output location for the pruned installation image.
If you are using the response file installation method, do not specify any languages or features in the response file that are not available in the pruned image, otherwise the installation will fail.
Pruning DB2 install images on Linux and UNIX
On non-Windows platforms, there is no utility available to prune installation images. Included with this article are two scripts (db2lnx32.sh and db2lnx64.sh) that can be used to prune DB2 images for supported 32 bit and 64 bit Linux distributions, respectively. This sample script removes the following:
- Documentation files for all languages except English and Japanese
- GUI installer (After removing this component, you can only use response file installation)
- License files for all languages except English and Japanese
- Language locales except English and Japanese
- Samples directory
The script should be run from the root directory of the installation image where the db2 and doc subdirectories exist. These scripts simply issue "rm" commands to remove the files and subdirectories corresponding to the components listed above. You should review and customize the sample scripts before using them.
Further pruning can be performed by removing some of the components. For
Linux and UNIX platforms, a file called ComponentList.htm is located in
the db2/linux
directory on the DB2 product DVD.
It lists components by three categories:
- REQUIRED
- TYPICAL
- OPTIONAL
The REQUIRED components should not be removed, but TYPICAL and OPTIONAL
ones can be removed if you do not need them. There is one compressed
archive file per component. File names corresponding to the components are
also listed and these files are located in the
db2/<platform>/FILES/
directory.
Some components show up in multiple sections, e.g. a component may show up
in both the REQUIRED and TYPICAL sections. A component cannot be removed
as long as it is listed in REQUIRED section. As mentioned earlier, you
should use the CUSTOM installation type (see Figure 1) when installing
from a pruned image. This allows you to uncheck any components that you
have removed from the installation image. You should test the pruned
installation image thoroughly to ensure that DB2 installs and functions
properly.
Conclusion
By using a DB2 response file installation, you can transparently install DB2 in your own application installer. This method of installation eliminates the need for user input and provides you with detailed and timely installation progress information through log files. You also have the option of pruning the installation image size in order to reduce its size. Using a response file installation is great for performing large-scale DB2 deployments or for embedding DB2 in your application's installation process.
Acknowledgements
The authors express their gratitude for the help received from Darin McBride of the IBM Toronto Lab.
Downloadable resources
- PDF of this content
- Sample DB2 pruning scripts for Linux (db2linuxprune.zip | 3KB)
Related topics
- "Leverage data partitioning for scalability and high performance on Linux" (developerWorks, Jan 2006) explores the performance and scalability advantages of the IBM DB2 Universal Database Data Partitioning Feature (DPF) in DB2 UDB for Linux, UNIX, and Windows.
- DB2 9.5 Online Information Center: The DB2 online (and searchable) documentation is your source for information on DB2 for Linux, UNIX, and Windows.
- Download a free trial version of DB2 Enterprise 9.
- Now you can use DB2 for free. Download DB2 Express-C, a no-charge version of DB2 Express Edition for the community that offers the same core data features as DB2 Express Edtion and provides a solid base to build and deploy applications.
- Visit the developerWorks resource page for DB2 for Linux, UNIX, and Windows to read articles and tutorials and connect to other resources to expand your DB2 skills.
- Download IBM product evaluation versions and get your hands on application development tools and middleware products from DB2®, Lotus®, Rational®, Tivoli®, and WebSphere®.