[Info-vax] What would you miss if DECnet got the chop? Was: "bad select 38" (OpenSSL on VMS)

[David Froble]

BlackCat wrote:
> On 18.09.2016 09:18, Paul Sture wrote:
>> On 2016-09-17, David Froble <davef at tsoft-inc.com> wrote:
>>> Stephen Hoffman wrote:
>>>> I'd be seriously tempted to announce the deprecation and eventual 
>>>> removal of DECnet, for that matter.
>>> Booo!  Hisssss!
>>>
>>> Ok, we know it's not secure.  Run at your own risk.
>>>
>>> I'm guessing that DECnet users use it only in house, for FAL and such, so if the 
>>> in house environment is secure, then security isn't an issue for DECnet.
>>>
>>> If it's not going to take up time and effort, then why kill it off?
>>>
>>> I personally find it can be useful.
>>>
>>> It sure is handy when you need to shutdown and re-start TCP/IP on a remote (but 
>>> in house) system.
>> I'd certainly miss one or two things that DECnet does:
>>
>> o - the ability to do a SET HOST 0 /LOG= to get a log / audit trail of software
>>     installations and configuration sessions.   Yes, many terminal emulators can
>>     do logging, but those logs aren't on the target system.
>>
>> o - using DECnet as a means of placing BACKUP savesets on another node, and
>>     restoring them from other nodes (where 'other' can be either local or
>>     remote).
>>     
>> o - DECnet tasks.  Useful but I haven't seen many customers use these.
>>
>> o - FAL
>>
> Surely many of the existing OpenVMS customers, like ours, are using applications that still use DECnet.
> So why would you want to make these unhappy? No one is asking for new functionality (bar a few minor improvements), but just
> continued support.

This!  This is the reality.  Is there any reason to piss off currently happy 
customers?

I'd guess that if DECnet is enhanced that many current users would NOT do 
anything to make use of new features.  If they needed more, they would have 
moved to something else long ago.

> Even though DECnet is a (very) mature product, I have yet to see the equivalent loadsharing and failover capabilities in other
> network protocols.
>