Bashing my head against a wall for 5 days now. db2daig.log included

daGGoth · #1 (**permalink**) 09-13-11, 18:17

Hey all. Long story short, i work for a datacenter. We have a db2 server running DB2 v9.5.201.346 Build level s080911. Our client machine is the same version. They can ping, telnet, and even resolve each other through dns. So they have communication. But a piece of software we use crashes as soon as we launch it. I have narrowed it down to a db2/network issue. So here is the log: (some text was removed)

2011-09-13-16.48.49.915000-300 I1H942 LEVEL: Event
PID : 3608 TID : 3456 PROC : ******.exe
INSTANCE: DB2 NODE : 000
EDUID : 3456
FUNCTION: DB2 UDB, RAS/PD component, pdLogInternal, probe:120
START : New Diagnostic Log file
DATA #1 : Build Level, 128 bytes
Instance "DB2" uses "32" bits and DB2 code release "SQL09052"
with level identifier "03030107".
Informational tokens are "DB2 v9.5.201.346", "s080911", "WR21421", Fix Pack "2a".
DATA #2 : System Info, 1564 bytes
System: WIN32_NT ****** 6.1 AMD64 Family 6, model 44, stepping 2
CPU: total:1 online:1 Cores per socket:1 Threading degree per core:1
Physical Memory(MB): total:4096 free:2804 available:1689
Virtual Memory(MB): total:8190 free:6829
Swap Memory(MB): total:4094 free:4025
Information in this record is only valid at the time when this file was
created (see this record's time stamp)

2011-09-13-16.48.49.915000-300 I946H333 LEVEL: Error
PID : 3608 TID : 3456 PROC : ******.exe
INSTANCE: DB2 NODE : 000
EDUID : 3456
FUNCTION: DB2 UDB, common communication, sqlcctcpconnr, probe:110
MESSAGE : DIA3202C The TCP/IP call "connect" returned an errno="10061".

2011-09-13-16.54.27.067000-300 I1281H313 LEVEL: Event
PID : 3472 TID : 1392 PROC : db2set.exe
INSTANCE: DB2 NODE : 000
EDUID : 1392
FUNCTION: DB2 UDB, oper system services, db2set_main, probe:40
CHANGE : CFG DB2SET: DB2OPTIONS: From: "-ao" To: "-ao"

2011-09-13-16.54.39.755000-300 I1596H313 LEVEL: Event
PID : 2132 TID : 2848 PROC : db2set.exe
INSTANCE: DB2 NODE : 000
EDUID : 2848
FUNCTION: DB2 UDB, oper system services, db2set_main, probe:40
CHANGE : CFG DB2SET: DB2OPTIONS: From: "-ao" To: "-ao"

2011-09-13-16.55.12.928000-300 I1911H310 LEVEL: Event
PID : 1680 TID : 3880 PROC : db2set.exe
INSTANCE: DB2 NODE : 000
EDUID : 3880
FUNCTION: DB2 UDB, oper system services, db2set_main, probe:40
CHANGE : CFG DB2SET: DB2OPTIONS: From: "-ao" To: ""

Someone please help me. I've been beating my head against the wall.... And i have very limited experience with db2

Marcus_A · #2 (**permalink**) 09-13-11, 19:55

Fixpack 2a is pretty old. It is very difficult to fix the problem with only the above information and without access to the system. I would suggest you try and get someone to help you that can log on to system (or walk you through some things on the phone) since you don't seem to know much about DB2.

n_i · #3 (**permalink**) 09-13-11, 21:40

To quote the oft neglected manual,

Quote:

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.

meehange · #4 (**permalink**) 09-14-11, 00:45

Easiest thing to test is if you can make a DB2 connection from the client to the DB, but I'm guessing n_i's post above covers the probably causes anyways...
The errors generated from a db2 connect to <db> from the command line will likely pinpoint where the config error is...

Internet Services

Web Development

Digital Marketing

Consumer Tech