Hi I am sure this is not a new one, and I am also going through the forum to find out answer to this one. Still if you can help .. Thanks.

I've setup db2 on linux and would like to connect to it from my java application on a different machine ( windows ) using the jdbc driver com.ibm.db2.jcc.DB2Driver.

I've read that we need to enable db2 to provide service over tcpip, and I've done these steps :
1) edit /etc/services to add this
server1 49000/tcp
2) db2 connect to sample
3) db2 "update database manager configuration using svcename server1"
4) db2stop
5) db2start
6) db2set DB2COMM=tcpip
7) db2stop
8) db2start
9) db2 "get database manager configuration"

Step (9) shows me that db2 tcp/ip service is set up in the configuration.

Also, "netstat -anp | grep 49000" shows me this :

tcp 0 0 0.0.0.0:49000 0.0.0.0:* LISTEN 9622/db2sysc 0

But I am not able to connect to this db2 instance from my java app, it says no route to the host.

Here is my connection configuration in Java :

dburl="jdbc:db2://server.ip.address:49000/sample:"
dbuser="db2inst1"
dbpassword="password"
dbenvironment="sample"
driverClass="com.ibm.db2.jcc.DB2Driver"

where, server.ip.address represents my internal server ip address.

To check connectivity of the server on that port, I also tried
telnet server.ip.address 49000

Even that indicates no connectivity to the server on that port.
I am able to otherwise ping to that server from my windows machine.

What does this mean ? is tcp/ip for db2 setup correctly ?

THANKS

the setup seems ok
can you display the complete message : sql message could indicate some hint
try to execute the program locally from the db-server..

it will take some time to do this on the server itself, but I did a quick test using telnet on that server and looks like it is running a service on that port.



[root@localhost ~]# telnet 10.10.93.50 49000
Trying 10.10.93.50...
Connected to 10.10.93.50 (10.10.93.50).
Escape character is '^]'.

So I'm sure it will work there.

From window's machine, this is what I get :

X:\>telnet 10.10.93.50 49000
Connecting To 10.10.93.50...Could not open connection to the host, on port 49000: Connect failed

X:\>ping 10.10.93.50

Pinging 10.10.93.50 with 32 bytes of data:

Reply from 10.10.93.50: bytes=32 time=37ms TTL=63
Reply from 10.10.93.50: bytes=32 time=1ms TTL=63
Reply from 10.10.93.50: bytes=32 time<1ms TTL=63

Ping statistics for 10.10.93.50:
Packets: Sent = 3, Received = 3, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 37ms, Average = 12ms

SQL Error is :

Db connection error: DbConnectionException: [ibm][db2][jcc][t4][2043][11550] Exception java.net.NoRouteToHostException: Error opening socket to server /10.10.93.50 on port 49,000 with message: No route to host: connect.

seems, there may be problem with the particular port #. Have you verified with your network guys that the particular port is open. You can also try changing the servicename by assigning it to a different port, say 50001 or 50002, if those ports are currently not used.

I am checking if there is anything like firewall sitting between the two machines that's blocking that port.

As far as the port availability is concerned, the port is available since it is not configured for any other service in /etc/services. And also db2start did not give any error indicating that port is already in use by some other service.

the database services at the server will continue to run even if you haven't assigned any port for the db2 services. the SVCENAME parameter & the TCP⁄IP port are used by the DBM to await communications from remote clients or local clients. So you can see at the DB server commands like DB2START etc are working good, but if the port is not opened for other remote clients, then from remote systems, you may not be able to access the database process on the target server.

Keep us posted with your finding.

Guys, I got it resolved ! The problem was that the local firewall on linux ( iptables ) was blocking access to this port. I added a line in there to allow incoming connections on 49000, and restarted the iptables service. That took care of it !

Thanks for all your help and time.