[Info-vax] SET TERMINAL /INQUIRE (was: Re: DECnet Phase IV broken after VSI update)

[Stephen Hoffman]

On 2021-10-30 23:00:00 +0000, Craig A. Berry said:

> When you do, you may need to have a look at the part of SYLOGIN.COM 
> that has the SET TERM/INQUIRE command.  In the boilerplate version that 
> comes with VMS, a rather long list of device types are excluded from 
> running that command, including "FT" which is what is   used by 
> interactive SSH connections, so by default, VMS won't know what kind of 
> terminal you have and lots of stuff doesn't work with terminal type 
> "Unknown."  If you delete FT from the list, your interactive sessions 
> will start getting the correct terminal type, but other things that 
> tunnel over SSH may break.

I'm guilty of most of that ginormous DCL abomination, as an earlier 
wide-open SET TERMINAL /INQUIRE was blowing up too much, and the 
terminal settings changes (particularly around performing that command 
on the console, and around clearing screens, IIRC) were derailing the 
regression tests. That DCL abomination because SET TERMINAL /INQUIRE 
wasn't all that much past a box of rocks at its own intended job. That 
all due to upward compatibility. And FT is (also) used for foreign 
terminals, which'll blow up other stuff that uses FT.

Pragmatically, ssh should have used its own terminal type, but that's 
probably not going to change now.

There are other issues lurking here, such as with the (lack of) 
TT_ACCPORNAM handling allowing identifying the source of arriving IP 
terminal connections.

It'd be interesting to see if ssh could be adapted to permit VT virtual 
terminal support, too.

Dredging up an old and semi-related discussion around DECterm and its 
use of FT, David Jones wrote "For FT devices, the field holding 
internal PID of the job whose bytlm was charged for the UCB 
(UCB$L_CPID) overlays UCB$L_LOCKID, so you can retrieve it using 
sys$getdvi with the LOCKID item code. You can convert the internal PID 
to an external PID and then sleuth the process that created the 
pseudo-terminal (e.g. DECW$TE_xxxx would be a decterm)."

It took a while to get OpenVMS detect the size of the original terminal 
window in an OpenVMS session, but at least that's been working for a 
while.

SET TERMINAL really shouldn't spew errors either, but the non-ANSI and 
busted-emulation terminals will. Old Tektronix certainly did. (4014 was 
pre-ANSI and did. 4125 had ANSI and didn't.) It's probably past time to 
rework all of this OpenVMS code though, and to adopt that ssh and 
telnet (ugh) and OPA0: serial or iLO are our connection paths, and just 
let truly fossil-grade terminals spew their errors, but... well... 
compatibility.


-- 
Pure Personal Opinion | HoffmanLabs LLC