Level: Intermediate Yasir Warraich (warraich@ca.ibm.com), Database Consultant,
IBM
Michael Gao (xmgao@ca.ibm.com), Manager, Business Partner Technical Enablement,
IBM
14 Feb 2003 Updated 20 Mar 2008 For large-scale deployments or for embedding a DB2® installation in
your own application installation, use this handy response file method of installing
DB2 that requires no user input. This article has been updated for DB2 9.5 for Linux®, UNIX®, and Windows®. It includes sample scripts for pruning the install image on Linux that you can customize to meet your own needs.
Introduction
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
unecessarily. 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:
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:
- Stop all DB2 processes and services by entering the following commands:
and
- Remove DB2 product. To do this programmatically, use the
db2unins command. For example, to
uninstall DB2 Enterprise Server Edition(ESE), you would use:
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.
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.
Download | Description | Name | Size | Download method |
|---|
| Sample DB2 pruning scripts for Linux | db2linuxprune.zip | 3KB | HTTP |
|---|
Resources Learn
Get products and technologies
-
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.
- Download
IBM product evaluation versions
and get your hands on application development tools and middleware products from
DB2®, Lotus®, Rational®, Tivoli®, and
WebSphere®.
Discuss
About the authors  | 
|  | Yasir Warraich is a DB2 Consultant from the IBM Toronto Lab where DB2 for distributed platforms is developed. He primarily works with IBM business partners in application development, performance tuning, porting and customized education. He has been working with IBM and DB2 for last ten years. Prior to working as a consultant he worked as an Advanced Technical Analyst for DB2. |
 | 
|  | Michael Gao is a manager in the Data Management ISV Solutions organization. Prior to that, he was a DB2 Consultant based at the IBM Toronto Lab where DB2 for distributed platforms is developed. He has presented at several international conferences and co-authored the book DB2 SQL Procedural Language for Windows, UNIX and Linux. |
Rate this page
|