Configuring DB2 For TSM On Unix Platform

Download as txt, pdf, or txt
Download as txt, pdf, or txt
You are on page 1of 3

Configuring DB2 and TSM in Unix / Linux

Configuration steps required for DB2 to work with TSM on Unix/Linux.

A few notes before configuring DB2 for TSM:

The TSM API bit level needs to match the DB2 bit level; the bit level of the OS
does not affect this. For example, if a 32bit DB2 Instances is installed on a 64bit
AIX OS, then the 32bit TSM API should be installed to match the bit level of the
DB2 instance.
Keep in mind that the db2adutl and dsmapipw utilities use the TSM API
environment variables (the DSMI variables) that are set in their current working
shell. Therefore, any changes to the DSMI environment variables will be seen
immediately by these utilities. However, DB2 utilizes the environment variables
from memory that are loaded when the instance is started. Therefore, any changes to
these DSMI environment variables require the DB2 instance to be recycled (i.e.
db2stop/db2start) for the changes to take affect.
If any of the TSM API files (such as dsmtca, libApiDS.a, or libApiTSM64.a) were
copied from one TSM API install directory to another, from the TSM B/A client
directory, or from one system to another, then it is suggested to uninstall the TSM
API, delete the TSM API install directory, and then reinstall the TSM API to ensure
that the appropriate bit level of the files exist in the correct location.

To ensure that DB2 and the TSM API are properly configured, perform the following
steps:
1. Log in with DB2 Instance owner (or use "su - db2inst1") and run:
db2level

From this output, verify if this is a 32 or 64bit DB2 instance


If DB2 is 32bit, install the 32bit TSM API
If DB2 is 64bit, install the 64bit TSM API

set | grep DSMI

Determine the current setting for the TSM API environment variables
DSMI_DIR should specify the:
/<opt or usr>/tivoli/tsm/client/api/bin directory if DB2 is 32bit
/<opt or usr>/tivoli/tsm/client/api/bin64 directory if DB2 is 64bit
the dsm.sys file must exist, or have link to it, in this DSMI_DIR directory
DSMI_CONFIG should specify a full path and file name for TSM user options file
(i.e., dsm.opt)
verify that "servername xyz" in this dsm.opt corresponds to an existing
"servername xyz" stanza in the $DSMI_DIR/dsm.sys
DSMI_LOG, if defined, should specify a directory that is read/writable by DB2

Note that the errorlogname parameter takes precedence over the DSMI_LOG variable.

if errorlogname exists in the stanza in the dsm.sys ensure the file specified
has RW access by the db2 user

2. Edit the file $HOME/sqllib/userprofile to include the DSMI variables from above

As of DB2 8.2 (DB2 8.1 fixpack 7), DB2 will only use the DSMI variables defined
in this $HOME/sqllib/userprofile.
Defining these DSMI variables solely in the $HOME/.profile is no longer
sufficient as they will be ignored by DB2.

3. At the bottom of the $HOME/.profile (for Korn shell) or $HOME/.bash_profile (for


Bash shell) or the equivalent for any other shell, source (i.e. execute/run) the
DB2 file $HOME/sqllib/db2profile. For example:

Add the following to the bottom of the $HOME/.profile

. /<db2home>/sqllib/db2profile
Note: <dot><space>/full/path/sqllib/db2profile

Add the following to the bottom of the $HOME/.bash_profile

source /<db2home>/sqllib/db2profile

By default, the .../sqllib/db2profile sources the .../sqllib/userprofile.


Therefore, the DSMI variables will still be exported into the DB2 user's shell.
To avoid confusion, it is recommended to remove the DSMI variables from the
$HOME/.profile or $HOME/.bash_profile (if they exist) and only define the DSMI
variables in the .../sqllib/userprofile

4. If using passwordaccess generate (in the dsm.sys), the DB2 database


configuration parameters TSM_OWNER, TSM_NODE, and TSM_PASSWORD must be set to NULL.
To verify, run:
db2 get db cfg for dbname | grep TSM
TSM management class (TSM_MGMTCLASS) = MYDB2CLASS
TSM node name (TSM_NODENAME) =
TSM owner (TSM_OWNER) =
TSM password (TSM_PASSWORD) =

The query will show blank values for the parameters that are already NULL.
If you need to update any of these DB2 database configuration parameters, run:

db2 update db cfg for dbname using TSM_NODENAME NULL

The value for TSM_MGMTCLASS will not affect this sign-in or authentication, so
it can be either NULL or populated with a valid management class. The mgmtclass
specified will only be used for the DB2 database backups, not the db2 logs.
The TSM_OWNER, TSM_NODE, and TSM_PASSWORD parameters should only be populated
when passwordaccess is set to prompt within the dsm.sys file.

5. Log out and log back in again as the DB2 user to set the environment

6. Verify the DSMI environment variables by running:


set | grep DSMI

7. Switch to the root user by running:


su

Note: do not use the "-". This will maintain the DB2 environment variables.

whoami

Verify that you are root


set | grep DSMI

Verify that the DSMI environment variables are still set appropriately

$HOME/sqllib/adsm/dsmapipw

Set the password for this TSM Node


If this fails,
1. Ensure the password being specified is correct or update the password on the
TSM Server with the command: UPDATE NODE the-tsm-nodename-for-db2 NewPassword
2. If passworddir is specified in the dsm.sys, delete the TSM.PWD file in this
directory
then run dsmapipw again.

exit

You should now be the DB2 user id again

db2adutl query

This should complete successfully, which verifies that the environment in the
current shell is properly configured

8. Recycle the DB2 instance so that the proper DSMI variables will be picked up by
the DB2 instance

9. Run the backup from DB2. For example:


db2 backup db dbname use TSM

You might also like