Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxn!ihnp4!cbosgd!ucbvax!info-vax
From: info-vax@ucbvax.ARPA
Newsgroups: fa.info-vax
Subject: VAX/VMS EMACS on PRO/350s -- XON/XOFF Problem
Message-ID: <9330@ucbvax.ARPA>
Date: Thu, 25-Jul-85 16:34:46 EDT
Article-I.D.: ucbvax.9330
Posted: Thu Jul 25 16:34:46 1985
Date-Received: Sat, 27-Jul-85 03:15:13 EDT
Sender: daemon@ucbvax.ARPA
Organization: University of California at Berkeley
Lines: 52

From: D. M. Rosenblum <DR01@CMU-CC-TE>

We have a problem here at Carnegie-Mellon University's School of Urban
and Public Affairs, that perhaps somebody can help us out with.  We have
a VAX/780 running VMS V3.7, and a number of DEC PRO/350's hooked up to
it by hard-wired 4800-baud lines (which are about to have their speeds
increased to 9600 baud).  We frequently use PRO/Communications V2.0
(under P/OS V2.0) to use the PRO/350's as terminals to talk to the VAX,
emulating VT102 terminals.  The editor that is most used on our VAX is
the VMS version of Gosling emacs.  (This is hard to change because most
of our users are non-hacking-oriented end-users who also use C-MU's
TOPS-20's, which have MIT (TECO-based) EMACS as their main editor, and
such users would not be too willing to learn another completely
different editor such as SOS or EDT.)

Here's our problem: at 4800 baud when PRO/Communications is emulating a
VT102 (and rarely when it's emulating a VT52), and at 9600 baud when it
is emulating either a VT52 or a VT102, emacs often puts stuff out to the
PRO/350 faster than the PRO can handle it.  By the way, the same problem
sometimes occurs on actual VT100 terminals and Gigis (VK100s) at either
speed.

Does anyone know of a way in VMS Gosling emacs to allow the system
(rather than emacs) to handle XON and XOFF characters for their usual
purpose (much as, in MIT TECO, one can use the FS TTY PAGE MODE flag to
do the same thing)?  Alternatively, does anyone know of a way to alter
emacs's internal definition of the VT102 to allow enough timing delays,
especially after insert and delete line, to make the problems we've
observed substantially unlikely?  (The definition of VT1xx terminals is
apparently hard-wired in Gosling emacs (it doesn't go through the
termcap file).)  Are there any other ideas as to how to deal with this
problem?  Any assistance would be appreciated.  Thanks in anticipation.

By the way, most of our PRO/350's are also hooked up to our VAX by
ETHERNET lines, and we have the standard PRO/DECnet software to support
these hook-ups.  Although this allows us to bypass PRO/Communications
entirely, it seems to fail miserably when one tries to run emacs because
PRO/DECnet's terminal emulation lacks much of what emacs expects to be
there.  If anyone has any suggestions for making emacs work through this
connection instead of through the communications lines, that would also
be appreciated.

        Daniel M. Rosenblum, Ph.D. candidate,
        School of Urban and Public Affairs
        Carnegie-Mellon University

        BITNET address: DR01@CMCCTE (? maybe DR01@CMU-CC-TE)
        MAILNET address: DR01%CMU-CC-TE@CARNEGIE
        ARPANET address: not sure -- DR01@CMU-CC-TE might work;
            if not try DR01%CMCCTE.BITNET@WISCVM or
            DR01%CMCCTE@CU20B or DR01%CMCCTE@COLUMBIA-20
-------