MANAGER@SMITH.BITNET (Mary Malmros) (08/03/87)
I've had a problem reported to me involving VAX Lisp and phone lines. The problem is this: when someone has dialed in and is using Lisp and they lose the line for whatever reason, the process does *not* die but stays active and continues to munch up CPU. Better still, the next person to connect to that phone port connects to the Lisp process as well. I've been told that this also happens when someone dials in to machine A, sets host to machine B, invokes Lisp on machine B, and then loses the line...process on A dies, but Lisping process on B stays on (network process without a host...spooky). I have not checked this out myself, however, so I can't say if this is the case. I don't understand why this is happening. I know that Lisp disables a lot of interrupts but I would not think that it could somehow ignore a disconnect unless someone decided to design it that way, and why would you do that? Furthermore, the problem seems to be exclusively confined to phone lines; if you request a disconnect through either Ethernet or our Ungermann-Bass LAN, the process is terminated. Anyway...HELP PLEASE. If this keeps up I'm going to have mega-problems once the students get back, what with security completely trashed and my CPU fallen into a black hole. Any information on changes in configurations of Lisp or terminals, confirmation of problem from other sources, SPR history, or (fond hope) news of patches from DEC would be much appreciated. +++++++++++++++++++++++++++++++++++ MMMMM MMMMM 2222 + + MM MM MM MM 222 222 + Mary Malmros + MM MM MM MM 22 222 + Systems Manager + MM MM MM MM 222 + Center for Academic Computing + MM MM MM MM 2222 + Smith College + MM MM MM MM 22222222222 + Northampton, MA 01063 + MM MMMM MM + (413) 584-2700 x3073 + MM MM MM + MANAGER@SMITH.BITNET + MM MM + + MM MM +++++++++++++++++++++++++++++++++++ MMMM MMMM
ANK@CUNYVMS1.BITNET (08/05/87)
I think it is not a vax lisp bug but how the phone lines are defined
$ SET TTXX:/MODEM/DISCONNECT/HANGUP
would allow the VAX to kill the process. However there seem to be some
terminal emulation comm packages which some users use that seem to
keep processes running long after the user *incorrectly* shuts his/her
PC off without logging out. Since that is certainly a mistake on their part
another program such as NANNY or other Deamon would have to kill hung
processes off.
Anil Khullar
{Ph.D. Prog in Psychology
C.U.N.Y. Grad. Center.
33 W 42 St. Box 295,
New York NY 10036 }
BITNET:ank@cunyvms1
INTERNET:ank%cunyvms1.BITNET@wiscvm.edu
==========================================================================
ON THE SEVENTH DAY GOD RESTED AND WATCHED CELTICS PLAY AT THE GARDEN
==========================================================================
[DISCLAIMER: They say after Boston there is heaven, I agree; I say after
LispM there is nirvana, they don't. This and other such opinion are
held dearly by me, my employers and the institution I represent do not
necessarily hold that view. I am sole culprit of such fantasies. No living
being is responsible, however unsolicited support is welcome]"Philip_Young.XSISHQ"@XEROX.COM (08/05/87)
> I've had a problem reported to me involving VAX Lisp and phone lines. > The problem is this: when someone has dialed in and is using Lisp and they > lose the line for whatever reason, the process does *not* die but stays > active and continues to munch up CPU... I'm afraid that all I can do is give you confirmation of the problem. In our case it happened when users logged into the VAX through the Ethernet (using Xerox protocols for virtual terminal connections). Every time a user lost a connection, the VAX Lisp process would enter what looked like a hard compute loop and bring our 750 to a standstill. We attempted without success to find the source of this problem. Since our use of VAX Lisp was temporary we put severe CPU limit restrictions on our Lisp users and left it at that. We always thought that the problem had something to do with our virtual terminal implementation but now it seems otherwise. Phil Young Xerox Corp.