Hello All,

Database backup is going to TSM on unix server with oslevel - 5.3 and db2level - v8.1FP14.
After the os upgrade backup not happened for few days , unix team has restarted the scheduler service. Also we found that the dsmi varaibles are not set.

So we have set the dsmi variables and unix team has restarted the scheduler services. Backup has triggered but failed with the error code:

SQLCA Information

sqlcaid : SQLCA sqlcabc: 136 sqlcode: -2062 sqlerrml: 42

sqlerrmc: /db2home/dbbrk01s/sqllib/adsm/libtsm.aÿ-53
sqlerrp : sqlubMWR
sqlerrd : (1) 0 (2) 0 (3) 0
(4) 0 (5) 0 (6) 0
sqlwarn : (1) (2) (3) (4) (5) (6)
(7) (8) (9) (10) (11)
sqlstate:

when issued the db2adult command, getting the same error code :
Error: Initialize session failed with ADSM return code -53.

can anyone help to resolve the above issue.

Thanks for your help in Advance.

Meena.s

maybe this is related
IBM - db2adutl behavior has changed in DB2 UDB Version 8

From http://publib.boulder.ibm.com/infoce.../msgs7548.html, RC=-53 means:

-053 E: DSM_RC_BAD_HOST_NAME An invalid TCP/IP address was specified.
Explanation
The TCP/IP address specified by the TSM client's TCPSERVERADDRESS setting could not be found on the network. Common reasons for this error include:
The TCPSERVERADDRESS client option specifies the wrong TCP/IP address for the TSM server".
The machine that hosts the TSM server is not on the network.
A network problem is preventing the TSM client from reaching the machine that hosts the TSM server.
System action
processing stops.

User response
Verify that the TCPSERVERADDRESS and TCPPORT settings have the correct values for your TSM server. Use your operating system's "ping" (or similar) utility to ensure that your machine can locate the machine that hosts the TSM server across the network. Try the operating again. If the problem persists, ask your TSM administrator for further assistance.


Use the suggestions given in the User response section. Check that the correct TCPSERVERADDRESS value is specifiec in dsm.sys, TSM is setup to accept connections from the server / DNS is setup to resolve the hostname to an IP address (using connecting to TSM via DNS).

Thanks all for your reply.

The problem got solved now.
DSM.SYS and DSM.OPT is having correct tcp id address. we were able to ping the same also.
but /etc/hosts holds different tcp id address. We have udpated the same and hence the backup is working fine now.

Many Thanks
Meena.s