Configuring DB2 For TSM On Unix Platform
Configuring DB2 For TSM On Unix Platform
Configuring DB2 For TSM On Unix Platform
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
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.
. /<db2home>/sqllib/db2profile
Note: <dot><space>/full/path/sqllib/db2profile
source /<db2home>/sqllib/db2profile
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:
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
Note: do not use the "-". This will maintain the DB2 environment variables.
whoami
Verify that the DSMI environment variables are still set appropriately
$HOME/sqllib/adsm/dsmapipw
exit
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