Kindly check dsm.sys whether tcpclientaddress option is specified.

Regards,
Wellington
+965 50369767

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Anjaneyulu Pentyala
Sent: Thursday, November 06, 2014 7:53 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Strange tcp_address value

Please check the /etc/host entry on your tsm server. /etc/host entry was added 
with wrong entry of ip address, how ever nodes are contacting by using DNS. 
check the nodes ip address in DNS.

nslookup <tcp_name>

Regards
Anjen

Aanjaneyulu Penttyala
Technical Services Team Leader
SSO MR Storage
Regional Delivery Center Bangalore
Delivery Center India, GTS Service Delivery
Phone: +91-80-40258197
Mobile: +91- 8497812222
e-mail: anjan.pentyala AT in.ibm DOT com
MTP, K Block, 4F, Bangalore, India




From:
Saravanan <evergreen.sarav AT GMAIL DOT COM>
To:
ADSM-L AT VM.MARIST DOT EDU
Date:
11/06/2014 08:40 AM
Subject:
Re: [ADSM-L] Strange tcp_address value
Sent by:
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>



TCP address is mostly choosen by network and you can try tracerte from both 
ends to identify the issue

By Sarav
+65-82284384


> On 6 Nov 2014, at 12:45 am, Thomas Denier 
> <Thomas.Denier AT JEFFERSON DOT EDU>
wrote:
>
> If I execute the command:
>
> select node_name,tcp_address from nodes
>
> on one of our TSM servers, two nodes have the same, very strange, 
> value
for the
> address: 192.168.30.4. The same address appears in the corresponding
output
> fields from 'query node' with 'format=detailed'.
>
> This address does not belong to my employer. All of the network
interfaces on
> the TSM server have addresses in one the officially defined private
address
> ranges. This has been the case since the TSM server code was first
installed.
> Given that, I don't see how a system with the address 192.168.30.4 
> could
ever
> have connected to the TSM server.
>
> I see session start messages for both nodes on a daily basis. There 
> are
no error
> messages for these sessions except for an occasional expired password 
> message. Even when that happens, subsequent sessions run without 
> errors, indicating that a new password was negotiated successfully. 
> The origin addresses for the sessions look perfectly reasonable. They 
> are in the
same
> private address range as the TSM server addresses, and in the right
subnet
> for the building the client systems are in. Every relevant statement I
have
> found in the TSM documentation indicates that the tcp_address field
should
> be updated to match the session origin address.
>
> When the TSM central scheduler attempts to request a backup of one of
the
> nodes it attempts to contact an address in the same subnet as the
session
> origin addresses.
>
> The TSM server is running TSM 6.2.5.0 server code under zSeries Linux.
The
> two clients are running Windows XP and using TSM 6.2.2.0 client code.
The
> two clients are administered by the same group of people.
>
> Does anyone know where the strange address could have come from, or 
> how to get the TSM to track the node addresses correctly in the future?
>
> Thomas Denier
> Thomas Jefferson University Hospital
> The information contained in this transmission contains privileged and
confidential information. It is intended only for the use of the person named 
above. If you are not the intended recipient, you are hereby notified that any 
review, dissemination, distribution or duplication of this communication is 
strictly prohibited. If you are not the intended recipient, please contact the 
sender by reply email and destroy all copies of the original message.
>
> CAUTION: Intended recipients should NOT use email communication for
emergent or urgent health care matters.

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com 
______________________________________________________________________