The case of the missing numeric ip format in TSM TCPCLIENTADDRESS

As part of the DB2 clustering solution using Tivoli Storage Automation(TSA) there were some customisations required to make the monitoring and backup procedures “cluster aware”. One of the customisations was to facilitate TSM  scheduler to point to the active DB2 node.

Read more on How to customise TSAMP start and stop scripts to make monitoring ...

Therefore if there is a DB2 failover from Server 1 to Server 2 , with all the associated resources failing over, such as ip address, DB2 instance and storage , TSM scheduler can point to the current active node and continue with backups as scheduled.

My initial idea was to use a CNAME as the address for the TSM scheduler to use. It turned out using the hostname caused some problems.     The fix was to adopt the usage of the parameters  TCPCLIENTADDRESS  and  TCPCLIENTPORT  in the dsm.sys   details. 

According to the IBM documentation , TCPCLIENTADDRESS is defined as :

“The tcpclientaddress option specifies a TCP/IP address if your client node has more than one address, and you want the server to contact an address other than the one that was used to make the first server contact.”

When the value associated with TCPCLIENTAddress is  resolved to a numeric TCP/IP address, the address is sent by the client to the Tivoli Storage Manager server. TSM records the address in the Schedules.Node.Addresses table .

Initially I used the hostname with the TCPCLIENTADDRESS . When a hostname is used with TCPCLIENTADDRESS , an attempt is made to resolve to a numeric TCP/IP address using standard DNS TCP/IP calls.  

If the value does not resolve , this causes a situation where the Scheduler cannot find the server. The incorrect name is stored in the TSM server.The fix is to use the numeric ip format.

TSAMP Cheat Sheet for DBA managing DB2 clustering (DBA DB2)