We are trying to perform TSM backups with DB2 V8 FP4 on AIX 5.x. We have tried on 2 different machines, one running AIX 5.1.0 and TSM client version 5.2.2; the other with AIX 5.2.0 and TSM client 5.1.6. We are able to backup to TSM successfully as long as the DB2 instance is defined to use a single partition, but if we change it to use 2 or more partitions, the backup command fails as shown below with an SQL2062N error. The partitions are defined as logical partitions that all reside on the same host machine. The db2nodes.cfg for 2 partitions looks like: 0 machineA 0 1 machineA 1 and the ".rhosts" file is set up correctly with the correct permissions. The test database works OK except when trying to backup using TSM. Backups to disk work fine. The error looks like: $ db2 backup db sample use tsm SQL2062N An error occurred while accessing media "/home/db2inst8/sqllib/adsm/libtsm.a". Reason code: "406". We have tried adding the option "open 2 sessions" and also the "parallelism" option, but this had no effect. The 406 reason code identicates that the "dsm.opt" file cannot be found. The DSM variables are defined in the DB2 instance user profile as shown below: export DSMI_CONFIG=/home/db2inst8/tsm/dsm.opt export DSMI_LOG=/home/db2inst8/tsm export DSM_DIR=/usr/tivoli/tsm/client/ba/bin export DSM_CONFIG=/home/db2inst8/tsm/dsm.opt export DSMI_DIR=/usr/tivoli/tsm/client/api/bin The "dsm.opt" file exists and is definitely found when
doing a TSM backup with a single partition database. We have tried configuring the "traceflag" and "tracefile" options in dsm.opt and they do create and populate the trace file when doing a backup of a single partition database. When the instance is changed to use 2 partitions, however, the trace file does not get created. This suggests either that the file isn't found (even though the file hasn't moved and the variables still have the same definitions as for the single partition case) , or else something went wrong during the processing before the file was located or at least before the trace functionality was activated, leaving us with an erroneous error message. When switching the number of partitions, we drop the current database, stop the instance (db2stop), change the db2nodes.cfg file for the new environment, then restart the instance (db2start). The instance starts OK and we can set database parameters (logretain, userexit) on each partition. A script ensures that we aren't attached or connected to anything, then sets both the DB2NODE variable and the DB2 client parameters (attach_node and connect_node) to the desired partition number before attempting to perform the backup command; e.g.: export DB2NODE=$N db2 set client attach_node $N connect_node $N We've tried doing an instance attachement, or a database connect, before issuing the backup, but this doesn't change the symptoms. We do not currently have any of the TSM parameters defined in the database configuration; e.g.: $ get db cfg for <database> |grep TSM TSM management class (TSM_MGMTCLASS) = TSM node name (TSM_NODENAME) = TSM owner (TSM_OWNER) = TSM password (TSM_PASSWORD) = These aren't necessary for the single partition case; it doesn't seem that they would be required for multiple partitions, but ... (?) Has anybody seen this problem before? Any ideas for what else we can look for? Any hints will be most appreciated, thanks! __________________________________ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools - ::: When replying to the list, please use 'Reply-All' and make sure ::: a copy goes to the list ([EMAIL PROTECTED]). *** To unsubscribe, send 'unsubscribe' to [EMAIL PROTECTED] *** For more information, check http://www.db2eug.uni.cc
