TSM losing connection with DB2

Platform
-------------------------------
OS = RedHat Linux ESE 4.6  32 bits
DB2 versiion = v9.1.0.3
DB2 code release = SQL09013
Tivoli Storage Automation (TSA)  =  SAFMP V310

Problem
--------------------------------
Assumption - installed OK - and system has been running OK
i.e scheduled backups and archived logging working OK .

The problem can be created with the following step:
1)Upon issuing a db2_kill   TSA restarts the instance - which it does so successfully.

But at that point :
a)issuing a "backup database MYDB online use TSM"
b)archival logging

both return a  (in db2diaglog):

TSM RC=0x0000006A=106 -- see TSM API Reference for meaning.

I can still issue a "db2adutl Query full db MYDB" and get a recordset from TSM

From the TSA perspective :
It looks like the TSA in the process of monitoring the instance , and sees the instance is down goes through a clean up process
via this code :
   $INSTHOME/sqllib/bin/db2gcf -t 60 -k -p ${NN?} -i ${DB2INSTANCE?}
kill -9 $(ps -fu $DB2INSTANCE | awk '{print $2 " " $8}' | grep " db2[a-z]" | awk '{print $1}')
kill -9 $(ps -ef | grep -v grep | grep db2chkau | awk '{print $2}')
su - ${DB2INSTANCE} -c "ipclean -a"

and the start up process

To recover back to the point of Archival Logging and Backups via TSM I can   reauthenticate  via :
1)stop TSA
2)run though the dsmapipw authentication

3)issue a db2stop \ db2start

this allows the backups and archival logging to start
4)start TSA

In a 24\7 environment -  the expectation  is to recover and maintain the TSM authentication

resolutions
-----------------------
The cause of the problem is to found in the TSA file "db2_start.ksh" - which is installed as part of the rsct/sapolicies , normally to be found on :
/usr/sbin/rsct/sapolicies/db2/db2_start.ksh

As part of the db2 recovery process the script issues the following command  as root:

$INSTHOME/sqllib/bin/db2gcf -t 60 -k -p ${NN?} -i ${DB2INSTANCE?}

Interogating this line indicates that :
1)the dbgcf command - which controls the Db2 Instance Command . This command is used to startstop or monitor the DB2 instance within the cluster setup
2)The -t switch is the timeout
3) the -K switch renoves al processes associated with he specified instance
4)the -p switch is the partition number
5)the -i switch is the instance

As part of the configuation of TSM per DB2 instance the following environment varibales are set up per instance . They are added to the : "<instance_home>/sqllib/userprofile"  as follows:

DSMI_CONFIG=/opt/tivoli/tsm/client/api/bin/dsm_db2.opt
DSMI_DIR=/opt/tivoli/tsm/client/api/bin
DSMI_LOG=/myInstance /tsmlog
export DSMI_CONFIG DSMI_DIR DSMI_LOG

The problem arises when the line is issued as root  : $INSTHOME/sqllib/bin/db2gcf -t 60 -k -p ${NN?} -i ${DB2INSTANCE?}
The environment variables are not   set up for root  which outline the path of the .opt file and log files .

The workaround is to add the following lines in the "/usr/sbin/rsct/sapolicies/db2/db2_start.ksh" . Ensure you add them just under the line : DB2INSTANCE=${1}

#######
## These lines fix the environment problems with TSA and TSM passwords
#######

DSMI_CONFIG=/opt/tivoli/tsm/client/api/bin/dsm_db2.opt
DSMI_DIR=/opt/tivoli/tsm/client/api/bin
DSMI_LOG=/${DB2INSTANCE}/tsmlog
export DSMI_CONFIG DSMI_DIR DSMI_LOG

#######
#######

Assuming your DB2 instances are all set up in a standard path format , this will cover all DB2 instances on the server .

 Ref:Jack Vamvas(http://www.dba-db2.com)