<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>
Hi Ghani:<BR> <BR> Do you have the QKGO TERMINAL TIMEOUT parameter set <BR>
to a positive number?<BR><BR> I like Bob Mills' solution of keeping the session active<BR> if that what the client wants. This assumes that you<BR> have enough licences to use one up for each client all day.<BR> <BR> In Bob Mills case you would want the QKGO TERMINAL TIMEOUT<BR>
parameter to be zero. i.e. no timeout.<BR> <BR> Some SSH Hosts automatically time out their clients. <BR> <BR> There is another timeout available it is called the <BR> ROLLBACK TIMEOUT. Its purpose is to give<BR> the user time to fix an error that occured while the<BR> update transaction is opened. If the user does not<BR> enter something in the allowed time then a timer exception<BR> is detected and the update transaction is rollbacked.<BR> I like to do foreign key checks and value checks before<BR> attempting the update thus although the database will<BR> also do them as well within the update transaction <BR>
there is a much better chance of a clean update. I use<BR>
deferred constraint checking as well. <BR> <BR> Some packet based networks drop the connection if a timer<BR>
exception has occurred.<BR>
<BR>
Quick tries to be nice and gives you a warning that the<BR>
session is about to timeout. There are two timeouts involved<BR>
timeout 1 to get the warning and timeout 2 for real.<BR>
<BR>
Enhancement: <BR>
<BR>
1) When an SSH Host automatically times out a client or<BR>
whenever there is an error on stdin or stdout<BR>
I think QUICK should exit.<BR>
<BR> i.e. the same as of you had hit the system exit key<BR>
except no IO attempts on stdin or stdout.<BR>
<BR>
2) Have an option in QKGO and PHRS<BR>
called KILL_ON_TIMEOUT. The QUICK process acts as<BR>
if the sytem exit key ( usually control_Z) has been hit<BR>
except no IO attempts on stdin or stdout. e.g. no timeout<BR>
warning.<BR>
<BR>
I have been in situations where I have had to decide to kill <BR>
QUICK sessions because they appeared to be hung. This is<BR>
not a lot of fun especially when there is a relational database attach <BR>
to the QUICK process. Indeed as we move forward into the SOX<BR>
and CSOX world manual interventions by programmers is just not <BR>
allowed. The activities of Jerome Kerviel of he French bank <BR>
Société Générale will bring application security to an even higher<BR>
focus.<BR>
<BR>
<BR>
<BR>
<BR>
<BR> <BR> Good luck,<BR>
<BR> Peter Bateman<BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR><BR><BR><BR>
<BLOCKQUOTE>
<HR>
Date: Thu, 31 Jan 2008 17:30:03 +0800<BR>From: abdghani@staroba.org<BR>To: powerh-l@lists.sowder.com<BR>Subject: QUICK on UNIX - Session Hang after Network Cutoff<BR><BR>Dear all,<BR><FONT face=Arial>I have a customer who is having problem with QUICK via Reflection remote connection. While QUICK is in session, the connection is lost and quick processes appear to be continually trying to read() from a pty which has no underlying telnet connection active any longer. The code path they enter when the pty is in this state causes all to be woken at once. </FONT><BR><FONT face=Arial>The system has so many 'quick' processes (depending on the number of sites connecting and lost connection) in this state that they are all waking/sleeping together and causing lots of extra CPU time in the scheduling related kernel code paths.</FONT><BR><FONT face=Arial>Powerhouse Version: 8.43.D1<BR>UNIX Version: HP-UX 11.2</FONT><BR>Appreciate any input.<BR>Thanks & regards,<BR>Ghani.<BR><BR></BLOCKQUOTE><br /><hr /> <a href='' target='_new'></a></body>
</html>