[Info-vax] SET TERM /TTSYNC on ancient VMS versions

[Johnny Billquist]

On 2018-08-16 23:11, hans.huebner at gmail.com wrote:
> Am Donnerstag, 16. August 2018 21:20:14 UTC+1 schrieb Johnny Billquist:
>> If you want to, and if you decide to use the signals in a different way
>> than the standard says, yes. The actual way it is defined that these
>> signals work, and are to be used, does not make it possible to use them
>> for flow control. Using them for flow control essentially violates the
>> standard.
> 
> You need to specify which standard you're talking about.  TIA-232-E defined how hardware flow control should be implemented, but that standard certainly came out after the first PDP11's were built.  When I did most of my asynchronous serial work in 1989-1995, the need for hardware flow control become very pressing indeed, because modems became faster and vendors started to implement their own compression protocols.  In that time span, solutions for hardware flow control were desired not only for the philosophical reason that in-band signaling should be avoided, but also because in-band software flow control reduced the amount of user data that could be transmitted over an asynchronous link, as the flow control characters had to be encoded so that they could be sent.

I'm talking about RS-232C, which came about in the late 60s, and which 
is what is most relevant when we talk about both PDP-11s and VAXen, 
since by the time the flow control variants in RS-232 were added, we're 
into the 90s, which is a time when DEC had already had this designed 
since a long time.

Yes, what you describe is true, and is the reason why this capabilities 
were added in. And at about the time you're talking about. I think it's 
pretty much mid 90s when it was defined.

> I would argue that software flow control undesirably mixes link layer with application layer functionality.  The issues that Stephen Hoffman pointed out regarding possible security problems that would be created by somehow escaping to the AT command layer of a (virtual) modem connection are also a testimony.  When we ran our (then) high-speed UUCP modem links in that time span, we always made sure that we had hardware flow control in our (sadly) Unix serial device drivers, that our USRobotics modems has hardware flow enabled and, of course, that escape to the AT command mode using +++ was switched off.  It just made sense like that.

The AT command set is a bit more special, and odd, compared to the flow 
control issue, but I agree that there are always some issues with 
in-band control communication.

> I've read what HELP SET TERM has to say about modem control again:  VMS V5.5 only implemented hardware flow control on serial lines for printers.  It is explicitly stated that /MODEM and /COMMSYNC are mutually exclusive and that the latter must not be used for interactive terminal lines.

I'm seriously surprised if there was hardware flow control for serial 
printers as well. DEC serial printers certainly used XON/XOFF anyway.

> Even with this information, it still seems to me that with /NOTTSYNC and a terminal that was fast enough, there is nothing in VMS that would prevent me from using Ctrl-S and Ctrl-Q for non-flow-control purposes, and that the VAX LISP manual is incorrect in stating that they cannot be bound due to "System restrictions".

There is nothing preventing you from using ^S/^Q for other things, if 
you just set the terminal line in the right mode and/or use the right io 
functions. Even if the terminal isn't fast enough.
And VAX LISP certainly could have allowed it, but it's a choice they 
made (I guess), that they wanted to keep the terminal interfacing 
simple, and use the standard modes.

   Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol