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:
Best Regards, Guy Przytula
Database Software Consultant
Good DBAs are not formed in a week or a month. They are created little by little, day by day. Protracted and patient effort is needed to develop good DBAs.
Spoon feeding : To treat (another) in a way that discourages independent thought or action, as by overindulgence.
DB2 UDB LUW Certified V7-V8-V9-V9.7-V10.1-V10.5 DB Admin - Advanced DBA -Dprop..
Information Server Datastage Certified http://www.infocura.be
-053 E: DSM_RC_BAD_HOST_NAME An invalid TCP/IP address was specified.
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.
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).
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.