authorplaceholder@QAOKIS.UUCP.UUCP (02/27/87)
I am posting this for a freind, If anyone has any suggestions please send
e-mail to myself or Steve. Thanks.
------------------------------------------------------------------------------
From uucp Fri Feb 27 14:07 EST 1987
>From sar Fri Feb 27 13:05 CST 1987 remote from ltuxa
To: sfbc!dfp
Subject: sam editor - lock-up problem
Cc: QAOKIS!swk dc003b!qahqjac jim rah ras
Dave: I've been experiencing some rather painful problems with the sam editor.
After editing for a while with sam, usually with several files open at once,
I periodically experience a lock-up condition that begins after the terminal
has been idle for a few minutes (1-2 minutes only). I find that any open files
that were not written are TOTALLY lost (per your recent mail, there is no way
to recover these files either.) I've had this problem at least 4 times in the
past two-three weeks and have lost some major editing changes, since I've been
using some unnamed (un-saved) buffers to hold temporary text. Although I've
changed my habits some by naming the buffers and writing intermediate results,
I thought you'd like to know. I really agree with you this is a VERY EFFICIENT
editor for the programming environemnt, but this shortcoming is almost unbearable.
Do you have any suggestions? Are others experiencing this type of problem,
or could it be something particular to my environment? I would really
appreciate anything you may suggest regarding this, because I would really
like to continue using sam.
Steve Richards AT&T LT H-210, Lisle, IL 60532 (312) 971-5193 ltuxa!sar
------------------------------------------------------------------------------
-Scott Kilgore
ihnp4!QAOKIS!swkgwyn@brl-smoke.UUCP (03/03/87)
I just now got my copy of "sam" and therefore don't have enough experience with it yet to give a definitive answer to your question. However, it's possible that you're being biten by a rather common problem among DMD users, namely that some host process decides to blather into your layer port while you're running downloaded code (such as the sam interaction module) that communicates with a host process (such as the sam file manager) using its own special protocol. Most DMD programs like this are not robust in the face of extra unexpected stuff being transmitted to them. It is essential before downloading a layer process to make sure that no spurious output will be sent to that layer. This means that any "biff"-like processes in that layer must be disabled, that "write", "wall", and "talk" not be allowed to find that layer, and that there be no spontaneous shell timeouts or other alarm- driven actions armed. You can avoid notifier processes like "biff" simply by not running them in the layer; you can avoid "write" etc. by reserving your "communication layer" for them and running downloaded stuff only in other layers; and you can avoid timeouts by setting TIMEOUT=0 in a Bourne shell, or equivalent in other shells. (If you have a DMD, I advise setting TIMEOUT=0 in the environment from your .profile, to avoid having to worry about it later.) I hope one or more of these hints solves your problem.