Converting from LAT to Telnet for DECServer modem farm

[VMSRox]

Hi,

I am attempting to convert some modems attached to a DECServer700 from using LAT to using telnet for outgoing communication from a VMS server.

I have gotten things working for the most part, but am looking for some advice from you knowledgeable folks!

The problem for me is that there are so many variables in this configuration, so I was hoping that someone might take a look at the settings in the attachment and let me know if you see any issues.

Since I am only experimenting with telnet right now, the modems are still configured for using LAT by default, however, telnet listeners are enabled also.

It may seems strange that I set the telnet session protocol to telnet while the telnet listener is set to use Raw TCP, but for some reason that combination seems to give the best results with our modem scripts. However, things still are not correct. Using these settings I am able to use our scripts to dialout, connect, download a file, etc. However, for some reason when using telnet much of the text that is displayed by the remote system is overwriting itself - as if linefeeds are not occuring correctly. If I use LAT with the same VMS terminal device settings to the same DECServer port then the lines display correctly from the remote host.

Thank you in advance for your help!

[Robert Gezelter]

VMSRox,

You really need some detailed evidence, but one possibility is that there is an increase of latency in the connection, which is causing X-ON/X-OFF to be lost due to buffer overflows.

For starters, ensure that smooth scroll is not enabled on the terminals. If it is, and disabling it changes the problem, you are looking at a flow control problem.

There are many other possibilities, a line montitor is extremely useful for diagnosing failures of this sort.

- Bob Gezelter, http://www.rlgsc.com

[Art Wiens · Accepted solution]

Don't forget about the Telnet characteristics for the ports on the terminal server:

Local> help set port telnet
DEFINE/SET/CHANGE PORT TELNET

Modifies Telnet characteristics for specified ports.

{DEFINE} PORT [port-list] TELNET [CLIENT] characteristics
{SET } [ALL ] [SERVER]
{CHANGE}

port-list affected ports

ALL all ports

SERVER modify server characteristics

CLIENT modify client characteristics (default)

Additional help available for:

CLIENT SERVER

All kinds of things you can "play with" in there ... as long as you can square away who's the client and who's the server ;-)

Good Luck,
Art

[Antoniov.]

Hi,
I think you should also define port hard type not ansi.
I prefer disable signal control and issue &D0 hayes command to modem (disable all signal control).
However, in my experience, modem works in unusual way. In the past, when I was wrinting a modem manager, I had to add a little delay (about 10 ms) after sending LF.

Antonio Vigliotti

[VMSRox]

Hi,

Thank you for the suggestions. I did do some rudimentary tracing with Reflections which made it clear that only CRs were being sent when using Telnet, while LAT was sending CRLFs.

Based on that I configured the port telnet server host linefeed parameter on the terminal server port. I also changed the listener type to Telnet; when it was set to raw the linefeed parameters didn't seem to have any affect. Thank you Art for mentioning the port telnet parameters - I was not aware of those prior to your post.

I then set the port type to Hard and disabled signal control.

With all of these changes, the telnet configured modems seem to be bahaving much better, although they still exhibit some flakiness with the modem scripts that we use. With the LAT modems the scripts work fine, with the telnet modems they sometimes work.

Thank you again. I will continue to experiment with some of the other settings as time allows. If I am able to work out the flakiness I will post the changes that helped. If anyone has any other suggestions I would love to hear them.

[Jim_McKinney]

> Reflections
> only CRs were being sent when using Telnet

Choose "Connection" from the top menu bar of a Reflection session. That will bring up the "Connection Setup" facility. Choose "More Settings" and you'll find a check box for "Send LF after CR". Just check and save.

[Art Wiens]

I'm not sure why you would want to disable signal control. If you have a "proper" modem cable between the t/s and modem and the port set for hardware (DSR) flow control (you can also specify a single direction for flow control ... ideally both ends are set for both directions), it "should" work properly.

I'm sure ethernet was invented by someone who had to deal with all this nonsense all the time!! Speed and duplex ... done ;-)

Cheers,
Art

[Jan van den Ende]

Hi,

I do not know if this solution can work for you, but we kept one Decserver ( + "forgot" to throw away two other, now dubbed "spare"),
just for this funtionality. And we also conveniently "forget" to remove the LAT startup. Plus one small segment of ethernet (avoiding any switches and other stuff out of our control),

Is this cheating? But it does the job!

Proost.

Have one on me (maybe in May in Nashua?)

jpe

[VMSRox]

Hi,

Thanks for the additional suggestions. I have re-enabled signal control - it doesn't seem to have any effect.

For some reason the telnet enabled modems just don't seem to be functioning as well as the LAT modems. We use modem scripts to do things like automatic login, report retrieval, etc. With LAT the scripts work very well, with telnet they mostly work. Sometimes with telnet the script does not correctly specify the username during the automatic login and has to redo it, sometimes text is garbled, sometimes the connection is dropped with no warning.

The fallback plan is to do as Jan suggested and just connect the DECServer to a private network hub and continue to use LAT. Unfortunately this also means that we'll have to get some IP controlled power switches so that we can remotely power cycle the modems when they need it.

Thank God (and Xerox / DEC) for ethernet!

[Antoniov.]

Did you try follow set up?
$ set term /lf=9

Antonio