Serving Telnet Clients

[Walter Miller_1]

Be sure when you create the telnet device that you specify "/protocol=telnet" as the default is NONE.

[RF Thomas]

/protocol=telnet only made things worse.

/perm allows for a data connection. If we try to connect to another OpenVMS system there appears to be no flow control resulting in a lot of lost data or "data over-runs".

Connecting to a telnet enabled print server we see the same behavior.

[Hoff]

Do go for a bigger buffer as a start: SET TERMINAL /ALTYPAHD -- as for flow control, that's something that I'd expect from telnet, and it does appear that you have ttsync enabled. Bigger buffers definitely helps with data overruns.

If you're going host-to-host, I'd be looking at a different solution. Neither LAT nor telnet does particularly well at running protocols. DECnet over LAT sort of works, but not really, for instance. I'd probably be looking at DECnet over IP, as I know that works.

I don't know that anybody has tried a telnet enabled print server in quite this way, most folks use the telnet symbiont or lpr/lpd for printing. Are you queuing and spooling and copying print files directly to the LTAu: device?

[RF Thomas]

The application involves control, download, upload of data from RS-232-C machine tools connected through LTA devices and now need to transition to TNA (telnet) devices.

The data stream consists of 7-bit ASCII, 7-bit ASCII with even parity, 7-bit EIA with odd parity, various protocols needing , , , along with BCC and LCC, etc.

One device sort of implements DDCMP with that vendor's improvements :(

Additionally, we need to have captive terminals that in the LAT world were treated as printers.

The VMS defaults for ttyahd is much too small. We have set it to 4096 and most of the data over-runs have gone away. We still get some very strange characters when initiating the connection.