SEO

How so I connect to a database on a different machine.

For instance if I want to connect to the same machine I do

db2 connect to sample

If this database is on a different machine how do I do it.

BTW I am an Oracle person and are familiar with tnsnames etc. Is the
concept the same here?

--
Steve

Hi Steve.
Well it kinda depends on how you wish to connect.
If you have DB2_COMM=TCPIP in your db2set, then I'm gonna assume you're
trying to connect through the db2 client on a different machine.

If you have the DB2 client on a different machine then you need to
catalog both the instance and the database first. On DB2 LUW this is
done in the following manner on the client PC:

DB2 CATALOG TCPIP NODE <nodename> REMOTE <ip> SERVER <portnr (50000)>
DB2 CATALOG DB <dbname> AT NODE <nodename>

Then you can connect with:

DB2 CONNECT TO <dbname> USER <username>

I hope this is useful to you.

(I might have made a typo somewhere since I typed this from heart).

Steve Rainbird wrote:
> How so I connect to a database on a different machine.
>
> For instance if I want to connect to the same machine I do
>
> db2 connect to sample
>
> If this database is on a different machine how do I do it.

"Jurgen Haan" <jurgen@fake.dom> wrote in message
news:47061dcf$0$238$e4fe514c@news.xs4all.nl...
> Hi Steve.
> Well it kinda depends on how you wish to connect.
> If you have DB2_COMM=TCPIP in your db2set, then I'm gonna assume you're
> trying to connect through the db2 client on a different machine.
>
> If you have the DB2 client on a different machine then you need to catalog
> both the instance and the database first. On DB2 LUW this is done in the
> following manner on the client PC:
>
> DB2 CATALOG TCPIP NODE <nodename> REMOTE <ip> SERVER <portnr (50000)>
> DB2 CATALOG DB <dbname> AT NODE <nodename>
>
> Then you can connect with:
>
> DB2 CONNECT TO <dbname> USER <username>
>
> I hope this is useful to you.
>
> (I might have made a typo somewhere since I typed this from heart).
>
> Steve Rainbird wrote:
>> How so I connect to a database on a different machine.
>>
>> For instance if I want to connect to the same machine I do
>>
>> db2 connect to sample
>>
>> If this database is on a different machine how do I do it.



Jurgen,

Thanks that is indeed very useful.

However I found a problem.

This is what happened.

$ db2 CATALOG TCPIP NODE ruby REMOTE ruby SERVER 50000
DB20000I The CATALOG TCPIP NODE command completed successfully.
DB21056W Directory changes may not be effective until the directory cache
is
refreshed.
$ db2 catalog db pear at node ruby
DB20000I The CATALOG DATABASE command completed successfully.
DB21056W Directory changes may not be effective until the directory cache
is
refreshed.

Then I tried to connect and got the following.

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


Any ideas?
--
Steve

Well, it seems that your server on 192.168.1.2 is not configure to talk
TCP/IP.

To check this, you can log in on the server, and execute a db2set.
if there's no line saying: DB2_COMM=TCPIP then you should probably add
this by using db2set.

Furthermore, if you do so, check in your /etc/services that there's an
entry like 'db2 50000/tcp'.
if not, add it. DB2 needs to know on what port to run its service.
And finally, check your DBM settings by executing a 'db2 get dbm cfg'
there should be a 'SVCENAME' please set this one to the corrosponding
setting in your services.

You can do this by, for example, executing:
'db2 UPDATE DBM CFG USING SVCENAME db2'

Now restart your instance (db2stop/db2start)

Good luck.

Steve Rainbird wrote:
>
> Then I tried to connect and got the following.
>
> $ db2 connect to pear
> SQL30081N A communication error has been detected. Communication protocol
> being used: "TCP/IP". Communication API being used: "SOCKETS". Location
> where the error was detected: "192.168.1.2". Communication function
> detecting
> the error: "connect". Protocol specific error code(s): "111", "*", "*".
> SQLSTATE=08001
> $
>
>
> Any ideas?

"Jurgen Haan" <jurgen@fake.dom> wrote in message
news:470634B1.5090403@fake.dom...
> Well, it seems that your server on 192.168.1.2 is not configure to talk
> TCP/IP.
>
> To check this, you can log in on the server, and execute a db2set.
> if there's no line saying: DB2_COMM=TCPIP then you should probably add
> this by using db2set.
>
> Furthermore, if you do so, check in your /etc/services that there's an
> entry like 'db2 50000/tcp'.
> if not, add it. DB2 needs to know on what port to run its service.
> And finally, check your DBM settings by executing a 'db2 get dbm cfg'
> there should be a 'SVCENAME' please set this one to the corrosponding
> setting in your services.
>
> You can do this by, for example, executing:
> 'db2 UPDATE DBM CFG USING SVCENAME db2'
>
> Now restart your instance (db2stop/db2start)
>
> Good luck.
>
> Steve Rainbird wrote:
>>
>> Then I tried to connect and got the following.
>>
>> $ db2 connect to pear
>> SQL30081N A communication error has been detected. Communication
>> protocol
>> being used: "TCP/IP". Communication API being used: "SOCKETS". Location
>> where the error was detected: "192.168.1.2". Communication function
>> detecting
>> the error: "connect". Protocol specific error code(s): "111", "*", "*".
>> SQLSTATE=08001
>> $
>>
>>
>> Any ideas?


Thanks Jurgen you have been very helpful.

I can now connect from "ruby" to a database on "amber" but not vice versa.
They both look to have been setup identically except that "ruby" is 64 bit
and "amber" is 32. This shouldn't cause a problem should it?

--
Steve

Steve Rainbird wrote:
> <snip>>
>>
>> BTW in case it matters we are currently using DB2 Express-C.
>>
>> --
>> Steve
>>
>>
>>
>
> Looks like this may be the problem. The machine the 64bit database is on
> has 6GB memory. DB2 Express-C has limit of 4GB I believe.
>
>

Not entirely sure about that.
I'm running an Express-C on a 64bit server with 16GB memory.
Ofc it only uses 4GB at the moment. (It's a failover machine for when
our WSUE machine goes offline. It's running a testenvironment on
express-C and when our pri. machine explodes, we can reinstall the
failover machine to run the WSUE. Financial matter, in case anyone is
wondering why the *** we're running an express-c on a 64bit machine).

In our production environment, we're using an 64bit linux db2 WSUE
machine using 16GB memory. Our clients are 32bit linux machines running
the db2 client. So we're using 32bit clients to connect to a 64bit db
server.

In our test environment, we're using an 64bit linux with 16GB running
db2 express-C to which 32bit linux machines running the db2 client are
connecting.

So I think, at least at one point, we have a very similar situation to
yours, and it works without a hassle. We even have 32bit windows
machines connecting to our test environment using QUEST and DB2CC.

What kind of errors do you get?

Regards, Jurgen.

Steve Rainbird wrote:
> <snip>>
>>
>> BTW in case it matters we are currently using DB2 Express-C.
>>
>> --
>> Steve
>>
>>
>>
>
> Looks like this may be the problem. The machine the 64bit database is on
> has 6GB memory. DB2 Express-C has limit of 4GB I believe.
>
>

That's true. But it just means that DB2 Express-C will only allocate a
maximum of 4GB. It does not mean that your machine is not allowed to
have more.

"Jurgen Haan" <jurgen@fake.dom> wrote in message
news:47064DC6.60200@fake.dom...
> Steve Rainbird wrote:
>> <snip>>
>>>
>>> BTW in case it matters we are currently using DB2 Express-C.
>>>
>>> --
>>> Steve
>>>
>>>
>>>
>>
>> Looks like this may be the problem. The machine the 64bit database is on
>> has 6GB memory. DB2 Express-C has limit of 4GB I believe.
>>
>>
>
> Not entirely sure about that.
> I'm running an Express-C on a 64bit server with 16GB memory.
> Ofc it only uses 4GB at the moment. (It's a failover machine for when our
> WSUE machine goes offline. It's running a testenvironment on express-C and
> when our pri. machine explodes, we can reinstall the failover machine to
> run the WSUE. Financial matter, in case anyone is wondering why the ***
> we're running an express-c on a 64bit machine).
>
> In our production environment, we're using an 64bit linux db2 WSUE machine
> using 16GB memory. Our clients are 32bit linux machines running the db2
> client. So we're using 32bit clients to connect to a 64bit db server.
>
> In our test environment, we're using an 64bit linux with 16GB running db2
> express-C to which 32bit linux machines running the db2 client are
> connecting.
>
> So I think, at least at one point, we have a very similar situation to
> yours, and it works without a hassle. We even have 32bit windows machines
> connecting to our test environment using QUEST and DB2CC.
>
> What kind of errors do you get?
>
> Regards, Jurgen.
>



This what another dba sent to me about the errors he is getting.

"I found where to configure it. However, when the database restarts, I get
the following error: I'm guessing at the licensing error. Perhaps the 64 bit
version requires a license in order to connect remotely.



Support for one or more communications protocols failed to start
successfully. However, core database manager functionality
started successfully.

Explanation:

Communication protocol support did not start successfully for one
or more protocols. Possible reasons can include the following:

o Communication subsystem configuration error.

o Communication subsystem call failure.

o Database manager configuration error.

o System call failure.

o Database manager licensing error. "

Thanks again for all your help.



--
Steve

Steve Rainbird wrote:

>
>
> This what another dba sent to me about the errors he is getting.
>
> "I found where to configure it. However, when the database restarts, I get
> the following error: I'm guessing at the licensing error. Perhaps the 64 bit
> version requires a license in order to connect remotely.
>
>
>
> Support for one or more communications protocols failed to start
> successfully. However, core database manager functionality
> started successfully.
>
> Explanation:
>
> Communication protocol support did not start successfully for one
> or more protocols. Possible reasons can include the following:
>
> o Communication subsystem configuration error.
>
> o Communication subsystem call failure.
>
> o Database manager configuration error.
>
> o System call failure.
>
> o Database manager licensing error. "
>
> Thanks again for all your help.
>
>

"Support for one or more communications protocols failed to start"

I think that means that TCPIP is activated in db2set, but the
combination of the /etc/services file and the SVCENAME parameter in "db2
get dbm cfg" do not match.

But I'm not entirely sure.

"Jurgen Haan" <jurgen@fake.dom> wrote in message
news:47065196.3030300@fake.dom...
> Steve Rainbird wrote:
>
>>
>>
>> This what another dba sent to me about the errors he is getting.
>>
>> "I found where to configure it. However, when the database restarts, I
>> get the following error: I'm guessing at the licensing error. Perhaps the
>> 64 bit version requires a license in order to connect remotely.
>>
>>
>>
>> Support for one or more communications protocols failed to start
>> successfully. However, core database manager functionality
>> started successfully.
>>
>> Explanation:
>>
>> Communication protocol support did not start successfully for one
>> or more protocols. Possible reasons can include the following:
>>
>> o Communication subsystem configuration error.
>>
>> o Communication subsystem call failure.
>>
>> o Database manager configuration error.
>>
>> o System call failure.
>>
>> o Database manager licensing error. "
>>
>> Thanks again for all your help.
>>
>>
>
> "Support for one or more communications protocols failed to start"
>
> I think that means that TCPIP is activated in db2set, but the combination
> of the /etc/services file and the SVCENAME parameter in "db2 get dbm cfg"
> do not match.
>
> But I'm not entirely sure.



Don't think so.

$ db2set
DB2COMM=TCPIP
$
$ grep db2c_db2 /etc/services
db2c_db2 50000/tcp
$


TCP/IP Service name (SVCENAME) = db2c_db2
Discovery mode (DISCOVER) = SEARCH
Discover server instance (DISCOVER_INST) = ENABLE



--
Steve