Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!amdcad!ames!ncar!mailrus!tut.cis.ohio-state.edu!osu-cis!mstar!karl
From: karl@mstar.UUCP (Karl Fox)
Newsgroups: comp.dcom.modems
Subject: Re: Packet Switching (X.25) and BBS
Message-ID: <934@mstar.UUCP>
Date: 26 Sep 88 20:26:48 GMT
References: <62@csnz.nz> <1988Sep25.001151.6452@lsuc.uucp>
Reply-To: karl@mstar.UUCP (Karl Fox)
Organization: Morning Star Technologies, Columbus, Ohio
Lines: 25

In article <1988Sep25.001151.6452@lsuc.uucp> dave@lsuc.UUCP (David Sherman) writes:
>To avoid ridiculous charges, you do indeed need to operate on a
>line-by-line basis.  We set up our calls (using X.29 to set the
>remote PAD when the call comes in) to have a packet transmitted on
>CR or any control character; that allows interrupt chars such as
>DEL, ctrl-C or ctrl-\ to send the packet.
>
>We make do fine with line-based editors (a souped-up version of
>"ed", the University of Toronto ed), a line-based version of
>"notes", etc.

If you have a directly attached X.25 interface, it can use X.29
commands to put the remote PAD into character-by-character mode when
using VI or EMACS and then return it to line mode when you go back to
your shell.  An external PAD connected via serial lines can't see the
tty ioctl() commands, and therefore can't detect the user's intent as
well.  Ioctl() commands can send X.29 commands to set echo, erase and
kill characters, forwarding characters for ksh or tcsh users, etc.

Even with a serial-line-connected PAD, however, a knowledgeable user
can log in, escape back to PAD command mode, change parameters to use
character-by-character mode, go back to data mode, and run VI.  Not
convenient, but it is possible.
-- 
Karl Fox, Morning Star Technologies ...!{att,osu-cis,pyramid}!mstar!karl