Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.UUCP
Newsgroups: comp.unix.questions
Subject: Re: sam editor
Message-ID: <5662@brl-smoke.ARPA>
Date: Tue, 3-Mar-87 14:33:47 EST
Article-I.D.: brl-smok.5662
Posted: Tue Mar  3 14:33:47 1987
Date-Received: Thu, 5-Mar-87 23:26:15 EST
References: <4800001@QAOKIS.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 25

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.