Silent But Exasperating: Automated Install of the IBM DB2 Client

Having made the leap over to IBM’s new "DB2 Client" ADO.Net driver for the U2 UniVerse database, we recently spent some time figuring out how to get it onto users’ PCs.  This turned out to be harder than I expected, and harder than it should be.

The new Data Client’s installer was actually a big selling point for us.  The previous database driver, UniOLEDB, used a proprietary install program that didn’t support automated, silent installs.  This means that someone from the user’s IT department had to visit each user’s desktop and 1) launch the install program, 2) click Next a bunch of times, 3) phone us and complain about how annoying this is.  Every install program that we’ve created or incorporated into our product for the last 10 years has supported silent installs, except this one.  

I was so giddy at the prospect of moving on to a proper installer that I assured our clients that we would now fully support silent installs without (ahem) actually trying to do one.  My optimism was based on the fact that 1) the new database client uses the same installer as IBM’s flagship database, DB2, 2) this installer was created using one of the industry standard tools, InstallShield, which has supported silent installs for ages, and 3) the DB2 Information Center‘s extensive documentation includes a section entitled "Silent Installation".  It sure looks easy when you read about it.

Unfortunately, it doesn’t quite work the way it’s described, and finding the specifics required quite a lot of Googling as well as some trial and error. 

Here’s what doesn’t work:

1) Installing without a response file.  This will launch the installer, but it will quickly abort, and the error message written to the log is enigmatic:

Action ended 20:06:46: DB2SetDB2INSTANCECA.2BC48F01_561E_4906_8321_946A9F5A90AA. Return value 3.
Action ended 20:06:46: INSTALL. Return value 3.
MSI (s) (E4:68) [20:06:46:607]: Product: IBM Data Server Runtime Client – DB2COPY1 — Configuration failed.

Presumably, the response file is mandatory.

2) The standard InstallShield command line switch for generating a response file in the Windows folder (-r).  I never thought that the Windows folder was a great place to put it — apparently IBM agrees.

3) The Response File Generator utility (db2rspgn).  Although this utility does, indeed, generate a response file, we had absolutely no luck when trying to use this response file to do an install.  Googling the problem suggested that many others had the same result, but I still have no idea what the solution is, if any.

4) Manually editing one of the sample response files, as suggested by the Information Center, might have worked if we actually had a sample response file.  The sample response files are apparently located on the "Information Integration Product DVD", but I’ve never seen such a beast.

Here’s what does work:

1) Run the installer normally (with no command line switches), then look in your %TEMP% folder.  Sure, enough, there’s a .rsp file left behind in there. 

2) This response file works just fine with the standard InstallShield parameters for a silent install.  For the current version of the DB2 runtime client, this is :

v9.5fp2_nt32_rtcl_en.exe /v"/qn RSP_FILE_PATH=<path of the .rsp file>.

The contents of the elusive response file are somewhat of a letdown.  Unless you need to install 2 different versions of the database drivers, you’re unlikely to ever want to change a thing.   Should you not have an Information Integration Product DVD at hand, feel free to use our response file as a sample:

PROD=RUNTIME_CLIENT
INSTALL_TYPE=TYPICAL
DB2_COPY_NAME=DB2COPY1
DEFAULT_COPY=YES
DEFAULT_CLIENT_INTERFACE_COPY=YES
DEFAULT_INSTANCE=DB2
INSTANCE=DB2
DB2.NAME=DB2
LIC_AGREEMENT=ACCEPT