[Info-vax] USB/DB9 terminal converter for RX2660

[Jan-Erik Soderholm]

Den 2016-06-03 kl. 15:25, skrev John E. Malmberg:
> On 6/3/2016 8:06 AM, Jan-Erik Soderholm wrote:
>> Den 2016-06-03 kl. 12:30, skrev VAXman- at SendSpamHere.ORG:
>>> In article <nirchj$5u7$1 at news.albasani.net>, Jan-Erik Soderholm
>>> <jan-erik.soderholm at telia.com> writes:
>>>> Den 2016-06-03 kl. 05:06, skrev Steven Schweda:
>>>>>> I'm not 100% sure what you are trying, [...]
>>>>>
>>>>> I'm with him.  Around here, most of the simple-minded (serial)
>>>>> system consoles (HP PA-RISC workstation, HP zx2000, Sun workstation,
>>>>> VAX, XP1000, ...) are connected to DECserver terminal server ports,
>>>>> which can be reached by LAT from my main Alpha system.  (I haven't
>>>>> tried it, but I suspect that I could arrange to use Telnet for that
>>>>> part, too.)
>>>>
>>>> Yes, if you have a DECserver new enough to have TCPIP. You do not say,
>>>> and I don't going to guess, but if it has TCPIP you simply connect to
>>>> the IP address of the server and to the IP port number of the actual
>>>> serial port.
>>>
>>> Why TCP/IP?  I connect to services from linhx via LAT.  There's LAT
>>> available for linux; I've not bothered looking into it for Mac as there
>>> are already way too many problems in Mac OSX -- especially, el crapitan
>>> -- to bother.
>>>
>>
>>
>> Why TCP/IP instead of LAT? Is that a joke? Do I realy need to
>> tell *you* that? But OK, for everyone else then...
>>
>> - LAT is not routable. You are restricted to the local LAN (subnet).
>> - PuTTY (and many other emulators) does not support LAT.
>> - You will probably find TCP/IP by default on more (client) platforms.
>>
>> Both the first and the second are enough as show-stoppers, of course.
>
> True enough, but LAT can give you an SS$_HANGUP notification if something
> happens to the connection.  With the reverse Telnet, you have to detect a
> command timeout.  And on outgoing VMS connections, (Back in the UCX 4.x
> days) I had to delete and recreate the TNA device after a disconnection.
>
> So if LAT is available, it does have some advantages over TCP/IP.
>
> Regards,
> -John
> wb8tyw at qsl.net_work
> Personal Opinion Only
>
>

OK. I responded to this privately since you copied me privately.
Then I can just as well copy my reply here also....
Jan-Erik.

-----------------------------------------------------------------

Yes, I'm fully aware of the LAT features, have been using LTA
devices for outbound connections from VMS to serial equipment
on factory floors since early 90's. Today all new setups use
TNA devices which are not just as stable as LTA devices, but
have other benefits.

Using a TNA device, we can either connect over a terminal server
to a serial device or connect directly to the device, if it has
a LAN port.

We recently moved from connections over terminal servers to PLCs
with a serial port, to PLCs with an Ethernet interface option.
Only change is in the TELNET CONNECT command, the application
code is unchanged. Cannot do that with a LAT connection (no, I
do not expect to find PLCs with built-in LAT...).

On the other side, we can use LTA and TNA devices using exactly
the same application code, so the move from LAT to TCPIP was easy.

There is requests now to connect another 30-50 additional equipment's,
most of them PLC based with Ethernet interfaces, to our system.

Just a comment to this specific line:

 > ...I had to delete and recreate the TNA device after a disconnection.

We create our TNA devices like:

$!
$  Telnet -
    /create <IP-addres> <IP-port> <TNA dev number> -
    /prot=none -
    /time=(noidle,recon=00:00:02)
$!

So if the line is disconnected (the remote unit is restarted or
whatever), the telnet driver in TCPIP will reconnect automaticly.

Note that this reconnect only happens when/if there is something
to send from the VMS side, so we also implement a "heartbeat"
feature in our applications where a special message is sent to
the remote unit each 15 sec. So within 15 seconds from a network
failure or remote unit restart, it is connected again.

The only thing I have not been able to get rid of, is all the
"Session TNAnnnn: attempt to connect to n.n.n.n:nnn failed;"
messages in operator.log. It just creates a growing log file,
nothing else...


Anyway, an back on target, suggesting to use LAT for a console
*today* is a joke. You are seriously limiting yourself in the
choice of clients...


Jan-Erik.