Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!eecae!netnews.upenn.edu!rutgers!att!ulysses!sfsup!jdt
From: jdt@sfsup.UUCP (J Tais)
Newsgroups: comp.databases
Subject: Re: Strange problems with Informix Perform
Summary: same problem over TCP/IP
Keywords: Informix perform nohangup?
Message-ID: <4723@sfsup.UUCP>
Date: 31 Jan 89 15:39:31 GMT
References: <34891@codas.att.com>
Organization: AT&T-BL, Summit N.J. USA 07901
Lines: 43

In article <34891@codas.att.com>, jaa@codas.att.com (James Anderson) writes:
> A user brings up the perform screen, enters the Add or Update mode.
> Something happens to the dialin port they are on and they get disconnected
> from the system. The Informix process starts to run wild grabbing as much
> usr and sys tics it can get (can tell by reading sar).
> a Who shows the user still logged in with no idle time. A stat on the tty
> usualy shows 0 idle read time and a write idle time (sometimes no write idle).

I remember a similar problem on my last project, but it happened when users
were rlogin'ed over TCP/IP and running perform on the remote machine.  We
had a persistent problem with rogue perform processes grabbing all kinds of
cpu time when users disconnected in abnormal ways or were terminated by the
idle-line watcher.  However, I think the problem went away when we upgraded
to the next release of [Wollongong] TCP/IP.

I don't really know the answer, but you're definitely not alone.

> The getty defs for the tty have HUPCL in them. There is no changing of this
> in any of the profile scripts.
> 
> Question: What is going on, and what can be done to prevent it?
> 
> The current solution is to look at ps for a perform or sperform that has a
> large time (>10.00) and kill them and their parents.

Yes, we set up a shell script to do just that, actually, identified pseudo-ttys
with no logged-in user and killed their procs.

Might be worth hacking up a C function to call using 'on beginning' and make
sure signal handling for SIGHUP is set the way you want it.  Since they seem
to trap SIGINT, maybe there's some other signal handling going on.  I dunno.
Perform is a strange beast.  Seems to handle boundary conditions very poorly.
I suspect there are fixed size tables for user functions, lookups, etc; when
you exceed them unpredictable things start to happen!  I have seen perform 
screens stop functioning when a new user-defined functions were added; also
seen lookup's fail to work when a screen had too many of them.  Never took 
the time to diagnose exactly when these things stop working.

Also, never could get ESQL to work from within sperform.  Had to run SQL 
calls in a child.  Is this a feature or a bug?

John Tais
jdt@sfsup.att.com