Personal tools
You are here: Home → DB2 → How To's → Configuring DB2 and TSM in Unix / Linux
Navigation
Log in


Forgot your password?
 
Document Actions

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
Security Awareness
Would you like your company to implement gamification into your security awareness program?





Polls