[Info-vax] VSI and Process Software announcement

[Jan-Erik Soderholm]

Den 2016-09-21 kl. 19:13, skrev corbettatprocessdotcom at gmail.com:
> On Wednesday, September 21, 2016 at 12:48:55 PM UTC-4, Jan-Erik
> Soderholm wrote:
>> Den 2016-09-21 kl. 18:33, skrev Hunter Goatley:
>>> On 9/21/2016 9:47 AM, Jan-Erik Soderholm wrote:
>>>> Anyway, I could not find a way to create similar network devices
>>>> using Multinet. At least not using the telnet part of Multinet.
>>>
>>> From the online help for MultiNet:
>>>
>>> $ TELNET /CREATE_NTY[=([PERMANENT] - [,NAME=logical_name] -
>>> [,TABLE=logical_name_table] - [,MODE={EXECUTIVE|SUPERVISOR}] -
>>> [/PORT=target-TCP-port] - host
>>>
>>> It should work the same way as what you're used to, albeit with NTY
>>> devices instead of TNA devices.
>>>
>>
>> OK, right. Found it. Page 152 in the "user guide". :-)
>>
>> Looks promissing. I do not see any equivalent switch for
>> /PROTOCOL=NONE that disables all telnet handling and makes it into a
>> "raw" communication line with nothing but the actuall data sent by the
>> application code on both ends of the line.
>>
>> We expect a "clean" line with no other data then "our" data.
>>
>> Except from that, it does seem to do the same thing.
>>
>> So it doesn't seem to be a fully replacement of TELNET /CREATE in
>> TCPIP Services. Maybe there is some other device type (than NTY)?
>
> The NTY deice does not do any telnet negotiations and just passes the
> data it gets from the connection to the reader and passes anything
> written to it to the connection.
>

But it still seems to intercept telnet-escape characters and it also
tries 3270 negotiations, if I did not misread the manual. I probably
did... :-)

> Devices can also be created and maintained using the Network Terminal
> Device Control Program (NTYCP).
>
> http://www.process.com/docs/multinet5_5/admin_ref/chapter_6.htm
>


Yep, that also looks promising. Only practical test can show
how it handles network outages and similar. Questions like if
the devices reconnects automaticly and similar.

It also has to stay connected even if the data is idle since
it is usually the "other" side (like an handheld barcode
scanner or a PLC) that sends first.

Thanks.

>
> regards Mike
>