hi all,

i have a problem my db2 client application :
after the server (DB2 7.1 no fixpacks on AIX4.3.3 ) ends up in a core dump (produced by an other application) the network services seems to be dead (ping works but telnet or else doesn't work anymore) and my client application hangs.
the client application is in C ,runs on Win2000 , DB2 Connect 7.1 ,no fixpacks and uses the CLI ODBC interface.

here is a fragment from the end of my trace file on the client :
"( StmtOut="Select count(*) from db2inst2.V2TSM" )


SQLPrepareW( )
<--- SQL_SUCCESS Time elapsed - +4,415000E-003 seconds

SQLExecute( hStmt=2:1 )
---> Time elapsed - +4,710000E-004 seconds
sqlccsend( ulBytes - 312 )
sqlccsend( Handle - 45309552 )
sqlccsend( ) - rc - 0, time elapsed - +9,550000E-004
sqlccrecv( )


[ Process: 496, Thread: 488 ]
[ Date & Time: 08/07/2004 10.41.45.000005 ]
[ Product: QDB2/NT 7.1.0.40 ]
[ Level Identifier: 03010105 ]
[ CLI Driver Version: 07.02.0000 ]
[ Informational Tokens: "DB2 v7.1.0.40","n010415","WR21254" ]



SQLAllocHandle( fHandleType=SQL_HANDLE_ENV, hInput=0:0, phOutput=&00423d94 )
---> Time elapsed - 0 seconds

SQLAllocHandle( phOutput=0:1 )
<--- SQL_SUCCESS Time elapsed - +1,967900E-002 seconds

SQLSetEnvAttr( hEnv=0:1, fAttribute=SQL_ATTR_APP_TYPE, vParam=3, cbParam=0 )
---> Time elapsed - +6,332100E-002 seconds

SQLSetEnvAttr( )
<--- SQL_SUCCESS Time elapsed - +3,471000E-003 seconds

SQLSetEnvAttr( hEnv=0:1, fAttribute=Unknown value 2457, vParam=0, cbParam=0 )
---> Time elapsed - +4,920000E-004 seconds

SQLSetEnvAttr( )
<--- SQL_SUCCESS Time elapsed - +3,263000E-003 seconds


[ Process: 488, Thread: 496 ]
[ Date & Time: 08/07/2004 10.43.50.000006 ]
[ Product: QDB2/NT 7.1.0.40 ]
[ Level Identifier: 03010105 ]
[ CLI Driver Version: 07.02.0000 ]
[ Informational Tokens: "DB2 v7.1.0.40","n010415","WR21254" ]



SQLAllocHandle( fHandleType=SQL_HANDLE_ENV, hInput=0:0, phOutput=&00423d94 )
---> Time elapsed - 0 seconds

SQLAllocHandle( phOutput=0:1 )
<--- SQL_SUCCESS Time elapsed - +5,784360E-001 seconds

SQLSetEnvAttr( hEnv=0:1, fAttribute=SQL_ATTR_APP_TYPE, vParam=3, cbParam=0 )
---> Time elapsed - +7,177800E-002 seconds

SQLSetEnvAttr( )
<--- SQL_SUCCESS Time elapsed - +7,186700E-002 seconds

SQLSetEnvAttr( hEnv=0:1, fAttribute=Unknown value 2457, vParam=0, cbParam=0 )
---> Time elapsed - +1,540000E-004 seconds

SQLSetEnvAttr( )
<--- SQL_SUCCESS Time elapsed - +1,624000E-003 seconds
"

thank you in advance,
gabim

Sounds to me like the network problem is probably causing the core dump in db2 on the server? I'd be surprised if it were the other way around.

Which problem are you trying to solve, the client hanging when the network connectivity goes whonky or the server crash?

fixpacks are probably a good start.

thank you for your answer,

the core dump on the db2 server is caused by a java db2 application.but this is not really my problem. the client application is the one i care. it normally makes a reconnect to all resources which it detects to be faulty : db2, mq series (in the case that i receive not "normal" return codes).
with the core dump i try to simulate what happens at enterprise level by one of our clients : if the os/390 machine with the db2 server on it will be down for maintenance it happens the same scenario - my client application hangs and waits infinite after a db2 call.
this problem (client hangs) appears , with the aix db2 server, only in the case of a core dump and not if i shut the machine down (normally or from the power button )or if i plug out the network cable. in this cases my client detects that the server is not present and tries to reconnect each minute.

gabim

I guess you'll have to contact IBM, I don't think the client should hang like that. Although the fact that the network isn't working sounds like more than just a DB2 issue.

i have the solution...
if i set on the client the KeepAliveTime parameter on a lower value (10min.) then the client detects quickly the broken connection and tries to reconnect.
the default value of this parameter is , on ~all OS's , 2 hours and i never tested my client with a broken connection so long.