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:

"Jurgen Haan" <jurgen (AT) fake (DOT) dom> wrote



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:

"Jurgen Haan" <jurgen (AT) fake (DOT) dom> wrote


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" <news.nospam (AT) rainbird (DOT) me.nospam.uk> wrote


BTW in case it matters we are currently using DB2 Express-C.

--
Steve

<snip>>
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.


--
Steve

Steve Rainbird wrote:
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:
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 (AT) fake (DOT) dom> 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.



--
Steve