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