Re: Tab vs. Supdup

[John Wroclawski <JTW@MIT-SPEECH>]

Hmmm, I guess I never got around to sending this before...
    
    From: CPH@MIT-OZ
    Subject: Tab vs. Supdup
    
        Date: Tuesday, 7 May 1985  15:45-EDT
        From: Gail Zacharias <GZ>
    
    Thanks for the advice; I will write a program to call STCHR% and set
    things up correctly.
    
You will also have to deal with the STMOD% jsys, see below.

    The problem is that when I use a dialup, I'm only getting 7 bits
    transmitted to me (apparently with even parity).  The supdup codes
    come get transmitted by OZ, but when I get them some of them don't
    have the eighth bit turned on.
    
DEC has the interesting idea that the whether or not parity is needed is
determined by the *line type* (i.e. hardwired, chaos NVT, PTY, etc.),
rather than by either the terminal type or a combination of the terminal
and line type, which would be correct. Chaos NVT's don't add parity.
Hardwired (incl. dialup) lines do, unless they're in binary mode. I
guess it's time we designed a fix for this.

    The other problem about the supdup input escapes is that when I send
    ^\ (octal 034) to OZ, nothing special happens; so none of the supdup
    escape sequences can be used.  Will STCHR% fix this too?
    
There are two VTS jsyi of interest, STCHR% and STMOD%. STCHR is for
telling the system about hardware-dependent characteristics of the
terminal, such as whether it can scroll or insert and delete lines.
STMOD is for making a choice among various different modes of terminal
operation that the system can support, such as wrap vs. scroll and how
end-of-page indications are presented. In the normal supdup case of
connecting over a net, both of these words are set by the server that
does the initial connection. To use a hardwired line you will have to
set both yourself.

To turn on ITP you have to set the TM%ITP bit using STMOD%. I don't
know why it's a mode, it seems more like a STCHR% characteristic to me.
Anyway, this will cause ^\ to work as the escape character for sending
bucky bits, etc. *However*, the implementation is incomplete - in
particular the flow control part of ITP is not there, since it is not
used for network terminals. Adding it would be moderately tricky; 
were you planning on using it? Also Twenex's handling of output
resets (%TDORS) isn't quite right, but that needs to be fixed
pretty badly anyway.

-------