🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: vmsnet.sysmgt
Article #108

Re: Lost LAT sessions

#108
From: Dean Banfield
Date: Mon, 25 Jan 1993 22:20
57 lines
3400 bytes
In article <0NXsXB1w165w@jeslacs.wimsey.bc.ca> Peter Smode <psmode@jeslacs.wimsey.bc.ca> writes:

>   - a SHOW USERS FULL will be missing the (server/port) address for the
>   LTAxxx: terminal
>   - the process will INHALE all available CPU time, at elivated priority.
>   This effectively turns the system into a dog.
>   - it is suspected that users terminal sessions just go dead in the
>   water with no terminal response. We are not sure as users are not
>   giving us good information when these situations occur.

We have a software product which experienced a similar problem when 
installed at one particular client.  We narrowed it down to the following
criteria:
	User logged on via LAT
	Hanging out in our product at our prompt (read wait on SYS$INPUT)
	User walks away, uses other session on terminal server, etc and 
	  forgets about his read prompt in our product.
	He then logs off terminal server without actually exiting from the
	  product prompt, or logging off that session independently.
	LAT sends a HANGUP message to the process, which attempts to
	  wind down the image.  This is unsuccessful and the image is
	  left disconnected from any LAT connection and gets very high
	  priority in the attempted wind-down.
We traced the problem to a set of CTL-C, CTL-Y trapping routines which we
had implemented.  In effect, the wind-down operation sent a CTL-C (or Y)
to the image to wind it down.  Our software, assuming that this was an
interactive user, trapped the signal and tried to return the user to the
product prompt.  Having no effective terminal any more, the software got
very confused and sucked down all available resources trying to re-issue
the product prompt.  

To stop the bleeding (we never found an elegant solution) we simply advised
the client to disable the CTL-C, CTL-Y trapping, which meant that when a 
user aborted out of our product, we allowed the system to wind it down in
its own (possibly nasty to us) way.  This DID stop the problem.

My advice: Try to find out what application user/application was "turned
off" in this way.  Approach the developer of the application with these 
ideas and see what falls out.  It may be difficult to track this down, but
in our case our image was easily identifiable to the system manager as the
one trying to wind itself down.  The user was impossible to find, since the
LAT stuff got disconnected early in the wind-down.

Hope this is of some help.

-Dean
--
===============================================================
Dean Banfield                 
Real Decisions Corporation   Voice: 203.656.1500
22 Thorndal Circle             FAX: 203.656.1659
Darien, CT  USA 06820        Email: dean@rdcalr.realdec.com
-- 
===============================================================
Dean Banfield                 
Real Decisions Corporation   Voice: 203.656.1500
22 Thorndal Circle             FAX: 203.656.1659
Technical Details
Message-ID: <DEAN.93Jan25172005@unix1.realdec.com>
Path: arc1-ca.pugleaf.net!sparky!uunet!unx1!dean
References: <0NXsXB1w165w@jeslacs.wimsey.bc.ca>

Show Full Headers
Complete Article Headers
Newsgroups: vmsnet.sysmgt
Path: arc1-ca.pugleaf.net!sparky!uunet!unx1!dean
From: dean@unix1.realdec.com (Dean Banfield)
Subject: Re: Lost LAT sessions
Organization: Real Decisions Corporation
Date: Mon, 25 Jan 1993 22:20:05 GMT
Message-ID: <DEAN.93Jan25172005@unix1.realdec.com>
In-Reply-To: Peter Smode's message of Fri, 22 Jan 93 15:27:20 PST
References: <0NXsXB1w165w@jeslacs.wimsey.bc.ca>
Sender: dean@rdcalr.realdec.com (Dean Banfield)
Lines: 57