Telnet sessions and TERMINAL/INQUIRE

[Pierre Goyette]

I just installed OpenVMS 8.2-1 on an I64 platform and enabled the Telnet service. When I telnet to the system, I noticed that the telnet server is not negotiating the terminal type and therefore, if I try to edit a file, I get a "vms %TPU-E-NONANSICRT, SYS$INPUT must be supported CRT" message.

I am not an OpenVMS expert but I think the problem is in the SYS$MANAGER:SYLOGIN.COM procedure and the TT_DEVPREFIX returns as "TN" and therefore does not execute the SET TERMINAL/INQUIRE command. As a test, I removed the "TN" option from the TT_NOINQUIR variable and that solved the problem but I am not sure why I had to do this.

What is the proper fix so that telnet sessions are properly setup for the terminal type and parameters dynamically for an 8.2-1 system ?

Tia,

Pierre Goyette

[Daniel Fernandez Illan]

Pierre
Generally a interactive connection use a terminal device with two letters to indicate type of connection (TX serial, LT LAT, RT DEcnet, NV X.25, TN TELNET, ...). For me, is a well idea to use set terminal/inquire for all INTERACTIVE connections. You are included (I thinks), telnet in terminal type who need /INQUIRE option.
Saludos.
Daniel.

[Steven Schweda]

I would say that you found a good solution.
What's a "proper" fix? I like yours.

It may be that in some environments, a Telnet
connection is likely to come from a source
which does not respond well to SET TERMINAL
/INQUIRE.

It is also possible for a user to add similar
(but different) code to his own LOGIN.COM.

[Karl Rohwedder]

I think, when you connect from another VMS host via DECnet or TELNET, the terminaltype is autmatically set correct, i.e. a SET TERM/INQ is not nec.

Are you connecting from non-VMS systems?

regards Kalle

[Pierre Goyette]

I am telnetting from a Windows PC. The other maybe related problem is that I noticed that the telnet server is not negotiating the terminal type. With the Telnet protocol, a server typically first sends out a IAC DO TTYPE to negotiate a terminal type. With OpenVMS, I do not see this in the telnet trace. Therefore, the telnet session has no idea what terminal type is connected to it.

I thought the problem was the TERMINAL/INQUIRE but I think there is another problem.

Comments?

Thanks,

Pierre

[Ian Miller.]

As part of establishing the telnet session some terminal information is exchanged. Parhaps the telnet client you use does not supply what VMS wants to known.

Certainly removing TN from the list of device types for which the SET TERM/INQ is not done will work.

I think devices are listed there where a SET TERM/INQ is may be unecesary or may cause problems.

[Pierre Goyette]

Ian,

I've tested several telnet clients (in fact, we are a major developer of connectivity software) and the problem is that the host is not sending out the IAC DO TTYPE which it should at the very beginning of a connection. I don't know why it isn't doing this. I did a clean new install of 8.2-1, I checked the ftp site and there do not appear to be any patches. Is there something to configure in the Telnet service ?

Thanks,

Pierre

[Walter Miller_1]

On your OpenVMS machine test the telnet option negotiation to itself to be sure it is negotiating terminal type.

$ telnet
TELNET> enable options
TELNET> connect yournode

You will see the telnet negotiation.

Look for:

SENT WILL TERMINAL TYPE
.
.
.
RCVD DO TERMINAL TYPE (don't reply)
RCVD SB TERMINAL TYPE SEND
SEND SB TERMINAL TYPE IS VT100

This will tell you if it will negotiate with itself. If this does not look correct try the

TELNET> enable debug

and examine the output for the negotiation you are looking for and the proper format.

[Pierre Goyette]

Walter,

Thanks for the idea.

What I discovered is that the difference with the OpenVMS Telnet client is that the client first sends a WILL TTYPE to which the server properly responds DO TTYPE and then they negotiate the terminal type. But this is very non-standard. Most telnet servers out there always send a DO TTYPE as the first data to the client and negotiations continue from there.

I am unsure why in this case, the client is sending it and the server is not sending it by default.

Regards,

Pierre

[John Gillings]

Pierre,

Some would argue that the (mis)behaviour of the SET TERMINAL/INQUIRE command when executed from non-interactive processes is a bug. There's at least one public domain utility that corrects this problem.

Attached is SET_TERM_INQUIRE.EXE - this is an OpenVMS Alpha image which you can execute unconditionally in SYLOGIN.COM or LOGIN.COM. If executed from a batch or network process it will simply return. If executed in an interactive process it will set the terminal correctly. It also preserves terminal page and width.

Try a google search if you want to find the source code.