reason code 168. db2 backup failure

[waire]

Hello,



We currently running TSM 5.2.6.0 server and TSM client 5.2.3.0 on AIX 5.1 32bit. The database is DB2 8.2. The problem occurs whenever i try to backup the database using the command "db2 backup db reg17db online use tsm" i get the error

SQL2062N An error occurred while accessing media

"/rmdata/REGION17/db2home/sqllib/adsm/libtsm.a". Reason code: "168".



The TSM API error documentation explains this as "password file not found". The password does exists, i have reset the password by setting the environment as root i.e DSMI_CONFIG, DSMI_DIR, DSM_DIR , etc, i then run the password utility dsmapipw reset api password and TSM server password for the node in question. I verify that TSM.PWD has been created. backup/achive client for this node will connect to TSM server and run a backup, but when i run "db2 backup db reg17db online use tsm" i get rc 168. i have done an api trace but nothing obvious in trace output. One thing i noticed was that when i do a q node region17 f=d tcp/ip address sometimes changes from the IP address of the box to a different address which is an alias address. The box runs HACMP but the node in question does not belong to a HA resources group..



Any help will be appreciated..



cheers



Wil

 

[Jeroen]

did you (re)start DB2 also with the environment settings for dsmi_config etc?

 

[cheffern]

For error 168

it *usually* can be 1 of 2 things

1) it cannot find the password file , ie, can't read it, no permissions on the file or the dir

2) the userexit compile wasn't quite right

my exp has shown tho - that you can do this

poke around for all the DB2's dsm*logs and delete them

b/c you want them to recreate - then -

in the dsm.sys file stanza for DB2, set a PASSWORDDIR of somehwere that you know the DB2 user can read

reset the passwd via the dsmapipw & the scheduler (very impt to do both here)

chmod 777 the passwd file

and try again

~

Let us know if that helps-

This error can be very tricky to work with...and could be something else all together...

 

[waire]

I had restarted the db2 instance on a few occassions after reseting the passwords.

Also, i have used the STANZA or Keyword PASSWORD in the dsm.sys to set the "password". Apparently, tsm api should be able to read the password when it is set in the dsm.sys file. I have also checked directory and file permissions (TSM.PWD) and they are similar to the permissions set for other nodes running as a HA resouce on the same box.



dir permission

drwxrwsrwx 7 root system 512 26 May 16:09 tsm_config



file permissions

-rw-r--r-- 1 root system 828 22 May 15:51 dsm.opt

-rw-r--r-- 1 root system 782 14 Jan 2002 dsm.opt.smp

-rw-r--r-- 1 root system 1696 25 May 11:36 dsm.sys

-rw-r--r-- 1 root system 971 14 Jan 2002 dsm.sys.smp

lrwxrwxrwx 1 root system 37 10 May 11:39 dsmtca -> /usr/tivoli/tsm/client/api/bin/dsmtca

-rwsr-xr-x 1 root system 1623590 15 Oct 2003 dsmtca.old

lrwxrwxrwx 1 root system 5 18 May 15:30 en_GB -> en_US

drwxr-sr-x 2 root system 512 18 May 15:28 en_GB.old

drwxr-sr-x 2 root system 512 18 May 14:56 en_US

drwxr-xr-x 2 root system 2560 24 Nov 2003 en_US.old

-rw-r--r-- 1 root system 413 20 Feb 2004 inclexcl.lst

lrwxrwxrwx 1 root system 41 10 May 11:40 libApiDS.a -> /usr/tivoli/tsm/client/api/bin/libApiDS.a

-rw-r--r-- 1 root system 2143692 15 Oct 2003 libApiDS.a.old

lrwxrwxrwx 1 root system 40 10 May 11:41 libXApi.a -> /usr/tivoli/tsm/client/api/bin/libXApi.a

-rw-r--r-- 1 root system 65397 15 Oct 2003 libXApi.a.old

-rw-r--r-- 1 root system 16734 14 Jan 2002 README.API

drwxr-sr-x 2 root system 1024 15 Oct 2003 sample

-rw------- 1 root system 127 26 May 16:09 TSM.PWD

drwxr-sr-x 2 root system 1024 16 Sep 2003 xopen





cheers

 

[cheffern]

Well ok, if you don't want to test using the PASSWORDDIR value to rule that out, then perhaps your only option is to run a trace on the API...

(Here is the fuel for the test, as pulled from an IBM website section on API issues:

"Function call dsmInit returns DSM_RC_NO_PASS_FILE (168), if the password file is not present in the directory specified by the PASSWORDDIR option.")



Set this in the DB2 dsm.opt:



TRACEFILE /some_directory/trace.out

TRACEFLAGS api api_detail verbinfo verbdetail timestamp



Then try again and check the logfile generated by the trace and see if you can get any further. This is a hard one to troubleshoot without being on the box and intimately knowing your env...



Remove those from the dsm.opt when you are done.

If you can't find any good info in there - you may recheck on the HACMP thing...what is different about it from others that work?



Good Luck.