Error connecting to V9 remote database

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

mairhtin o'feannag - 23 Apr 2007 07:34 GMT

Hello,

I'm having problems connecting to my new v9 db box. The pertinent
information is below:

DB2_db2inst1 60000/tcp
DB2_db2inst1_1 60001/tcp
DB2_db2inst1_2 60002/tcp
DB2_db2inst1_END 60003/tcp

TCP/IP Service name (SVCENAME) = DB2_db2inst1

[db2inst1@mairhtin db2dump]$ db2set
AUTOSTART=yes
DB2COMM=tcpip

SQL30081N A communication error has been detected. Communication
protocol
being used: "TCP/IP". Communication API being used: "SOCKETS".
Location
where the error was detected: "67.170.223.55". Communication
function
detecting the error: "connect". Protocol specific error code(s):
"10061", "*",
"*". SQLSTATE=08001

db2 catalog tcpip node homesvr remote 67.170.223.55 server DB2
_db2inst1
db2 catalog db sample as sample2 at node homesvr

Database 2 entry:

Database alias = SAMPLE2
Database name = SAMPLE
Node name = HOMESVR
Database release level = b.00
Comment =
Directory entry type = Remote
Catalog database partition number = -1
Alternate server hostname =
Alternate server port number =

Node 1 entry:

Node name = HOMESVR
Comment =
Directory entry type = LOCAL
Protocol = TCPIP
Hostname = 67.170.223.55
Service name = DB2_db2inst1

Any help would be appreciated.

Mairhtin O'Feannag

Reply to this Message

situ - 23 Apr 2007 08:18 GMT

> Hello,
>
[quoted text clipped - 50 lines]
>
> Mairhtin O'Feannag

does u'r remote server started ??

Reply to this Message

mairhtin o'feannag - 23 Apr 2007 09:42 GMT

Yes, the remote server is started and I can connect to it
locally.

>> Hello,
>>
[quoted text clipped - 52 lines]
>
> does u'r remote server started ??

Reply to this Message

situ - 23 Apr 2007 09:55 GMT

> Yes, the remote server is started and I can connect to it
> locally.
[quoted text clipped - 65 lines]
>
> - Show quoted text -

since ur able to connect locally , i guess the problem is with
firewall settings

Reply to this Message

Knokmans - 23 Apr 2007 13:38 GMT

-Maybe stupid remark, but is there an entry for DB2_db2inst1 in your
client's services file ??

-If it is still not working, try a totally different socket and SVCENAME
(e.g. db2cdb2inst1 50000/tcp). As far as i know the sockets 60000+ are
installed only in an ESE environtment (for partitioning puposes), so try
socket 50000 (default by install).

Knokmans

> Yes, the remote server is started and I can connect to it
> locally.
[quoted text clipped - 63 lines]
>>
>> does u'r remote server started ??

Reply to this Message

mairhtin o'feannag - 26 Apr 2007 03:14 GMT

Ok, Update.

I changed the name of the service on the server machine, made it
50000, altered the client connect (catalogd node/db) and now the error
is VERY odd.

From the server machine :

db2cdb2inst1 50000/tcp
DB2_db2inst1 60000/tcp
DB2_db2inst1_1 60001/tcp
DB2_db2inst1_2 60002/tcp
etc.

the catalog statement on the connecting machine :

catalog tcpip node homesvr remote 67.170.223.55 server 50000;
catalog db sample as sample2 at node homesvr;

DB2 LIST NODE DIRECTORY : (on client machine)

Node Directory

Number of entries in the directory = 1

Node 1 entry:

Node name = HOMESVR
Comment =
Directory entry type = LOCAL
Protocol = TCPIP
Hostname = 67.170.223.55
Service name = 50000

then, connect to sample;

Error message:

SQL1337N The service "db2cdb2inst1" was not found.

I have no idea how the service could not be found, since I don't
explicitly supply the service name, it's picked up from the server
machine !?!?!?!?

Mairhtin

Reply to this Message

Knokmans - 26 Apr 2007 12:28 GMT

I assume your server is Unix/Linux....
if it is Windows replace /etc/services by
c:\windows\system32\drivers\etc\services.

On your server be sure :
-db2 get dbm cfg |grep SVCE
TCP/IP Service name (SVCENAME) = db2cdb2inst1
- cat /etc/services|grep db2inst1
db2cdb2inst1 50000/tcp
- db2set
DB2COMM=tcpip
- restart the db2instance:
db2stop [force]
db2start

On your client: catalogging seems to be OK except for the fact you enter:
-catalog db sample as sample2 at node homesvr
this means, when connecting to the database you have to enter
- db2 connect to sample2 [user <username> using <password>]
instead of db2 connect to sample (without 2).

Knokmans

> Ok, Update.
>
[quoted text clipped - 41 lines]
>
> Mairhtin

Reply to this Message

mairhtin o'feannag - 27 Apr 2007 05:25 GMT

I have done just that several times. Currently the SVCENAME is set to
50000, which is why I cannot understand the reference to db2cdb2inst1
on the connecting machine. It is obviously being "picked up" from the
server side of the conversation. Then it complains (actually DB2
complains) that it cannot find the service :

SQL1337N The service "db2cdb2inst1" was not found.

Mairhtin

> I assume your server is Unix/Linux....
> if it is Windows replace /etc/services by
[quoted text clipped - 65 lines]
>>
>> Mairhtin

Reply to this Message

Knut Stolze - 27 Apr 2007 08:46 GMT

> I have done just that several times. Currently the SVCENAME is set to
> 50000, which is why I cannot understand the reference to db2cdb2inst1
[quoted text clipped - 3 lines]
>
> SQL1337N The service "db2cdb2inst1" was not found.

Just a guess: do you have "db2cdb2inst1" in your /etc/services file on the
client system set to port 50000?

Signature

Knut Stolze
DB2 z/OS Utilities Development
IBM Germany

Reply to this Message

Knokmans - 27 Apr 2007 12:53 GMT

You can give a db2 ? <message> on the commandline. I quote:

db2 ? SQL1337N
SQL1337N The service "<service-name>" was not found.
Explanation:
The system cannot resolve the port number associated with the
service-name. Possible causes are:
o An incorrect service-name value was specified when the TCP/IP
node was cataloged.
o The correct service-name was specified, but was not defined
in the client's services file.

Federated system users: this situation can also be detected by
the data source.

User Response:
Make sure that the service-name specified when cataloging the
TCP/IP node is a correct name, and that it is defined in the
local services file.
Federated system users must also ensure that the name is defined
in the services file at the data source.

>> I have done just that several times. Currently the SVCENAME is set to
>> 50000, which is why I cannot understand the reference to db2cdb2inst1
[quoted text clipped - 6 lines]
> Just a guess: do you have "db2cdb2inst1" in your /etc/services file on the
> client system set to port 50000?

Reply to this Message

Knut Stolze - 23 Apr 2007 11:08 GMT

> Hello,
>
[quoted text clipped - 11 lines]
> AUTOSTART=yes
> DB2COMM=tcpip

Stupid question, maybe, but you did restart the DB2 server after setting the
DB2COMM registry variable?

> SQL30081N A communication error has been detected. Communication
> protocol
[quoted text clipped - 9 lines]
> _db2inst1
> db2 catalog db sample as sample2 at node homesvr

The V9 manual shows the following explanation for SQL30081.

---------------------------------------------------------------------------
If <protocol> = TCP/IP, <function> = connect, <rc1> =
ECONNREFUSED/WSAECONNREFUSED, AIX (79), Windows (10061), linux (111), SUN
(146), HP (239), the attempt to connect was rejected. Possible causes:

* The remote database server has not been cataloged correctly at the
client. In a client-gateway-server scenario, ensure the host entries are
cataloged correctly on the gateway. See the Quick Beginnings guide for
assistance.
* The database manager configuration file at the server has not been
configured properly with the proper communication parameters. Check that
svcename has been configured properly with the TCP/IP service name or port
number and that the port number is unique. If database manager
configuration parameters have been updated at the server, the database
manager must be stopped and re-started for the changes to take effect.
There might be a mismatch between the TCP/IP service name or port number
specified on the server and on the client. Ensure the service name maps to
the correct port number by checking the services file. You can check this
by reading the services file or checking the output of "netstat -a".
* The DB2COMM environment variable at the server does not specify the
communication protocol used by the client. Check that TCPIP has been
specified. Issue db2set to see what has already been set. Issue db2set
DB2COMM = TCPIP to set the value.
* The database manager at the server has not been started, or has not
been started successfully, or has gone down. The server should have
returned SQL1063, and not SQL5043. If you set the database manager
configuration parameter, diaglevel, to 4 using, db2 update dbm cfg using
diaglevel 4, prior to issuing db2start, the administration notification log
will provide detailed information on which protocols were started
successfully. Check the administration notification log.
* The server might be too busy to handle the volume of incoming
connections at this time.
* Network failure, contact your network administrator. You can try a
test using the protocol tester, pctt, to verify this is not a DB2 problem.
---------------------------------------------------------------------------

Signature

Knut Stolze
DB2 z/OS Utilities Development
IBM Germany

Reply to this Message