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

[Jan-Erik Soderholm]

Den 2016-06-04 kl. 00:48, skrev John E. Malmberg:
> On 6/3/2016 9:45 AM, Jan-Erik Soderholm wrote:
>> Den 2016-06-03 kl. 15:25, skrev John E. Malmberg:
>>
>> OK. I responded to this privately since you copied me privately.
>
> The private copy is because of a stupid Thunderbird default that I did not
> notice in the early morning.  It was not intentional.
>

No, I never thought or said that it was intentional... :-)

> While past versions of thunderbird just told me that it did not have an
> outgoing e-mail set up and send nothing, this version appears to get
> creative and pick one of my e-mail profiles and use it.
>
> I have not done professional VMS programming since leaving HP, but before
> that was doing similar factory automation to that which you describe with
> some of the same migrations over time.

Was that in the BaseStar time frame?

>
> The PLCs were always communicated over a network protocol, not telnet or LAT.

Depends on what you mean with "network protocol". Are you talkning about
some of the PLC manufacturers own protocols? I have found it hard to
get VMS "drivers" (within reasonable budgets) for that.

Or are you simply talking about some in-house message protokoll
between your VMS application and the PLC application? That is
what we use. PLC sends some message and VMS application replies
with an ACK or a NACK with error codes.

No telnet or LAT is involved at all. Note that the TNA devices are
setup using "/protocol=none", so they are "raw" and the line only
sees what the applications sends from each side. It is just a socket
but I leave the TCPIP handling to TCPIP. The applications still
thinks they are talkning to a TXnn physical terminal.



>
> The main use of Telnet/Lat was data entry terminals and barcode scanners.
>
>> 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.
>
> I am not sure that option was available on the older TCP/IP stack.
>

Not sure what your definition of "older" is either. :-)

> The software package that we used was written for physical terminal ports,
> which when though a terminal server equivalent pair over 802.4 network.
> When the 802.4 vendor went out of business is when we switched to LAT.
>
> The TCP/IP use resulted from someone deciding to have us handle the
> terminals and scanners in a site over 1000 miles away instead of installing
> local computer resources.

Right, we had TNA ports pointing at one remote sites like 100, 400
and 800 Km away. Doesn't matter for the application, of course.

>
> For local use LAT performance was superior.
>

Doesn't matter how "superior" it is, if you can not reach the
equipment using LAT due to the fact that it is unroutable.

> But we ended up with so many DecServers and LanTronix terminal servers that
> I fixed the program provided with the older decservers to actually backup
> and restore all the properties of the DecServers we had and also work with
> the LanTronix terminal servers.
>

Yea, that is an issue. The new Lantronixes are web based and does
not have the old "DEC-like" CLI. Pitty...

> I also had a program that scanned the NCP database for terminal servers
> "MOP?" mac addresses and it would connect to all the terminal servers
> registered and back the configurations up on a weekly basis.
>

Yes, that is something one do not need anymore (NCP registration).

> Both of those scripts ended up on one of the Freeware volumes, but I do not
> know if anyone else ever used them.
>
>> 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...
>
> It is good joke, since I have never used LAT for a console before working
> at HP, and I do not remember if the HP setup used LAT or not.
>
> When I worked on VMS as a customer, the only time I needed access to the
> physical console is when I was doing something local to the box like
> hardware servicing or a major operating system upgrade.  Both of which were
> very infrequent events.
>
> Of course I am a dinosaur that is still using a mouse pad that failed Y2K
> testing.
>
> Regards,
> -John
> wb8tyw at qsl.net_work
>
>

I need console access (not physical access) to re-config the FC
interfaces (using wwidmgr) whenever there is a change in the SAN
envoronment, such as 6 month ago when they completely replaced
an older IBM DS8000 with an IBM Storwize V7000. Did that over
a couple of weekends from home 170 Km away for 3 systems.

I also need console access when there is any major trouble that
need console access (doesn't everyone?).

Major OS upgrades doesn't need my local precense either.
V8.2 to V8.4 was completely done remotely including coping
of the installation (ISO) media.

My point is that most sites benfits to hook up their concoles
for network access.

Jan-Erik.