Article View: vmsnet.sysmgt
Article #108Re: Lost LAT sessions
From: Dean Banfield
Date: Mon, 25 Jan 1993 22:20
Date: Mon, 25 Jan 1993 22:20
57 lines
3400 bytes
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!deanReferences:
<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