Database administration for fun and profit

Defining different TSM options for multiple DB2 instances

I had been struggling with an obscure problem recently. I needed to set up several DB2 instances on a Microsoft Cluster Server and configure them for TSM backup and log archiving. That would have been a relatively easy task if it were not for the fact that those instances belonged to different cluster resource groups. Each group had its own virtual IP address and host name, and could be brought online or moved to another cluster node independently. For this reason each resource group required a separate TSM node defined for it, which, in turn, called for a separate set of TSM configuration options.

Ordinarily, the TSM configuration file is specified for the client applications by an environment variable, DSMI_CONFIG. Unfortunately, environment variables on Windows can be specified only at a system-wide level or at an individual user level, and there was no obvious way to define DSMI_CONFIG separately for each DB2 instance. As a result all DB2 instances shared the same TSM configuration, which was not what I needed.

In theory you can override system-wide TSM options by including new options in the BACKUP command:


It appeared though that not all options had effect when specified in this manner; in particular, including “-nodename=...” and “-passwordaccess=generate” did not seem to work. I also tried to define these options with the VENDOROPT database configuration parameter, with the same disappointing result.

Finally, I came across a possible solution while browsing the TSM manuals. There is a DB2 registry variable, DB2_VENDOR_INI, which can be used to specify a file containing third party environment variables. Such a file should contain variable name and value pairs, each pair on its own line, like this:


For each DB2 instance I created a vendor initialization file, containing an appropriate value of DSMI_CONFIG, and set the registry variable:

db2set -i db2inst1 DB2_VENDOR_INI=n:db2profsdb2inst1db2inst1.env

Once each instance was restarted, it had its own TSM configuration.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.