470,641 Members | 1,823 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 470,641 developers. It's quick & easy.

SQL30081N after RESET DATABASE CONFIGURATION

Hi NG,

I wanted to reset the database (manager) configuration with
RESET DATABASE CONFIGURATION
and
RESET DATABASE MANAGER CONFIGURATION

After doing this, I rebooted server and client and restarted IBM Universal
Database 8.2.
But now, I couldn't connect to my database anymore :-( getting the following
message:
SQL30081N Kommunikationsfehler. Verwendetes Kommunikationsprotokoll:
"TCP/IP". Verwendete Kommunikations-API: "SOCKETS". Position, an der der
Fehler festgestellt wurde: "[*there_was_the_ip*]". Kommunikationsfunktion,
die den
Fehler feststellte: "connect". Protokollspezifische(r) Fehlercode(s):
"10060",
"*", "*". SQLSTATE=08001

How could I fix the problem?

I would be glad for any help!
Cheers,
Ina
Feb 17 '06 #1
7 6725
Ive seen this problem before. Check whether you lost the following
registry value:

db2set DB2COMM=tcpip

-Michel

Ina Schmitz escreveu:
Hi NG,

I wanted to reset the database (manager) configuration with
RESET DATABASE CONFIGURATION
and
RESET DATABASE MANAGER CONFIGURATION

After doing this, I rebooted server and client and restarted IBM Universal
Database 8.2.
But now, I couldn't connect to my database anymore :-( getting the following
message:
SQL30081N Kommunikationsfehler. Verwendetes Kommunikationsprotokoll:
"TCP/IP". Verwendete Kommunikations-API: "SOCKETS". Position, an der der
Fehler festgestellt wurde: "[*there_was_the_ip*]". Kommunikationsfunktion,
die den
Fehler feststellte: "connect". Protokollspezifische(r) Fehlercode(s):
"10060",
"*", "*". SQLSTATE=08001

How could I fix the problem?

I would be glad for any help!
Cheers,
Ina


Feb 17 '06 #2
Ian
Ina Schmitz wrote:
Hi NG,

I wanted to reset the database (manager) configuration with
RESET DATABASE CONFIGURATION
and
RESET DATABASE MANAGER CONFIGURATION

After doing this, I rebooted server and client and restarted IBM Universal
Database 8.2.
But now, I couldn't connect to my database anymore :-( getting the following
message:
SQL30081N Kommunikationsfehler. Verwendetes Kommunikationsprotokoll:
"TCP/IP". Verwendete Kommunikations-API: "SOCKETS". Position, an der der
Fehler festgestellt wurde: "[*there_was_the_ip*]". Kommunikationsfunktion,
die den
Fehler feststellte: "connect". Protokollspezifische(r) Fehlercode(s):
"10060",
"*", "*". SQLSTATE=08001

How could I fix the problem?


RESET DATABASE MANAGER CONFIGURATION wiped out the setting for SVCENAME
(i.e. which tells DB2 which TCP port to listen to for connections!)

You need to set it back to what it was and then restart your instance.
Feb 17 '06 #3
Michel Esber wrote:
I´ve seen this problem before. Check whether you lost the following
registry value:

db2set DB2COMM=tcpip


The db2set will not be affected by the RESET, but the port on which your
instance listens is set to nothing. So the TCP/IP protocol can effectively
not be used and you have to set the port (SVCENAME) again.

--
Knut Stolze
DB2 Information Integration Development
IBM Germany
Feb 17 '06 #4
"svcename" in dbm cfg may be got reset to null , which is need by
remote client . Try "db2 -v update dbm cfg using svcename 50000" .
50000 is the default tcp port for DB2 UDB on windows. This may be
various and changable .

Cheng

Feb 18 '06 #5
Hello again,

thanks for your answers!
The "svcename" set to null really was the problem.
I would like to reset my dbm cfg again not sitting at the server, but at a
remote client. Is there any possibility to specify the svcename already
during my reset?

Otherwise, I can't update the svcename on my own, because after resetting my
dbm cfg I can't connect to the database, of course ;-) Then I would have to
ask anyone sitting at the server to update it.

Would be great if you also know a solution to this problem.
Cheers,
Ina
Mar 1 '06 #6
If you are at a remote client and want to change parms. of the remote dbm
then you need to use:
1) The Admin. Tools, ie Control Center, access the instance and change its
communications parms. Ypu'll need the SYSADMIN id for that instance.
Stop/Start the instance.
2) Use TelNet or whatever to start a local session on the remote server at
your wkstn. Isuue the db2 update dbm cfg using svcename command.
Stop/start the instance.

Shut the TelNet session or the Control Center.and go from there to update
your local client files.

HTH, Pierre.

--
Pierre Saint-Jacques
SES Consultants Inc.
514-737-4515
"Ina Schmitz" <we*@inalein.net> a crit dans le message de news:
du*************@news.t-online.com...
Hello again,

thanks for your answers!
The "svcename" set to null really was the problem.
I would like to reset my dbm cfg again not sitting at the server, but at a
remote client. Is there any possibility to specify the svcename already
during my reset?

Otherwise, I can't update the svcename on my own, because after resetting
my dbm cfg I can't connect to the database, of course ;-) Then I would
have to ask anyone sitting at the server to update it.

Would be great if you also know a solution to this problem.
Cheers,
Ina


Mar 1 '06 #7
Ina Schmitz wrote:
Hello again,

thanks for your answers!
The "svcename" set to null really was the problem.
I would like to reset my dbm cfg again not sitting at the server, but at a
remote client. Is there any possibility to specify the svcename already
during my reset?
You have to have an attachment to the server instance (see the ATTACH
command). The DB2 control center does the attach under the covers for you
in case you are a "Mausschubser". ;-)
Otherwise, I can't update the svcename on my own, because after resetting
my dbm cfg I can't connect to the database, of course ;-) Then I would
have to ask anyone sitting at the server to update it.


Well, you can run the update from the client. You just have to make sure
that you set the SVCENAME _before_ DB2 is restarted. The thing is that the
reset becomes effective after the restart of the engine. Thus, you should
still be able to connect to the server (from the client) until that restart
took place.

--
Knut Stolze
DB2 Information Integration Development
IBM Germany
Mar 3 '06 #8

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

1 post views Thread by alederer | last post: by
2 posts views Thread by xcb7226 | last post: by
4 posts views Thread by Asphalt Blazer | last post: by
reply views Thread by Troels Arvin | last post: by
2 posts views Thread by dimeuleh | last post: by
1 post views Thread by Korara | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.