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

[Stephen Hoffman]

On 2016-10-07 06:11:14 +0000, Michael Moroney said:

> Stephen Hoffman <seaohveh at hoffmanlabs.invalid> writes:
> 
>> On 2016-10-06 22:04:01 +0000, Dirk Munk said:
> 
>>> Stephen Hoffman wrote:
>>>> On 2016-10-06 14:53:14 +0000, Dirk Munk said:
> 
>>>>> Build a replacement in pure IP, and tell us when it's ready.
>>>> 
>>>> DIRECTORY /FTP works fine without DECnet, and supports domain names.
>>>> Available since V6.2.
> 
> Not good enough.  The great thing in the old days was that just about 
> any program that used RMS could access remote files via DECnet, without 
> any network awareness whatsoever.

I certainly don't prefer grafted-on widgets and tools, but there are a 
lot of these around.

>>>> SFTP support, a decent client for SMB, and, yes, IP-based FAL-like  
>>>> support would be nice.  Particularly with encryption and authentication.
> 
> Exactly.  An IP based FAL based on sftp or similar, where 
> network-unaware programs can access remote files via RMS just like you 
> could do something like $ RUN NODE::DISK:[DIR]PROGRAM.EXE on any VMS 
> system with DECnet. This time, securely.

Which also entails moving DTLS and TLS deeper into the system 
environment and integrating it into more parts of the platform, and 
probably also eventually a migration to LDAP and Kerberos. and a whole 
pile of other related work.

>>>> But DECnet is still dead.
> 
> IP FAL might be the stake through the heart that's needed.

Which should be a generic remote file system interface, because there 
will be changes here.   An interface where SMB or NFS or sftp or 
otherwise can be slotted in underneath the file system.  This likely 
also involves FTPS and/or IPsec, and some policy mechanism to shut off 
any in-the-clear FTP client access.  This because — as has been stated 
in this and other threads — we're not going to have FAL servers 
everywhere, and FTP itself has issues with encryption and 
authentication and firewalls.

>>> So the bottom line is that DECnet is dead, but 40 year old DECnet has  
>>> functionality that today's IP can not offer to VMS. Or am I wrong?
> 
>> Oddly, the rest of the universe gets by with ssh, netcat, file shares  
>> and related.
> 
> Yes and the rest of the world gets by without shared-everything clusters

Because for folks that need clusters, shared-everything clusters don't scale.

> and M$ PCs filled with bloatware that have to be rebooted every few days.

Management and marketing folks need to understand and look at the 
problems and benefits of competing platforms to their customers, and to 
be able to clearly state a case for purchasing your products.   Not 
that I particularly think that Microsoft Windows is competing with 
OpenVMS, though Windows Server certainly is.

Development folks need to look at those other platforms for their 
technical negatives, as well as detailed examinations for ideas that 
are useful and clever and worth reuse and improvements.   This as part 
of creating future versions of the local organizations products, 
updating user interfaces and tools, and related.   There are a number 
of features of Microsoft Windows that are vastly superior to OpenVMS, 
and that your customers would greatly appreciate having access to.

Development folks also need to look for the negatives in their own 
products.  As an example of this, consider OpenVMS clustering.   
There's a wide-open SCS network transport.  There's no authentication.  
 There's no distributed scheduling, no job control, no distributed 
logging.   There's no mechanism for bridging clusters.   The file-based 
management and set-up — what are we up to, ~20 files, manually 
configured, moved back to the system disks for patches and upgrades — 
is just hilariously bad.   There's no easy mechanism to boot into a 
cluster without manual intervention, and OpenVMS lacks any sort of 
profile mechanism.   Programming APIs aren't there, either — there's 
ICC and the DLM and add-on bits for LDAP and the various network stacks 
and VCI, but those all tend to be rather low level interfaces, and 
require a fair amount of knowledge and experience to work with, fairly 
complex to properly set up failover or DT configurations, and many of 
the APIs tend to be somewhat less than secure.   There are 
clustering-related scaling issues for folks that might want larger 
numbers of hosts, too — clusters larger than even the theoretical limit 
of OpenVMS clusters are not particularly rare in the industry, and 
eventually some OpenVMS folks — if the license prices, features and 
support work out for customers and for VSI — will be looking for larger 
configurations.   All of which gets into discussions of Apache Mesos, 
of work around AvailMan, OpenVMS Management Station and otherwise, of 
scaling the interconnects and the bandwidth, and a whole host of other 
cluster-related topics.    Doing patch management and cluster rolling 
upgrades gets interesting, too — that all needs to be much easier.

OpenVMS clusters are great and work exceptionally well for tasks that a 
number of OpenVMS customers have — when the customers can afford 
clustering — and parts of clustering are exceedingly elegant and 
well-integrated into the OpenVMS environment.   Other parts of 
clustering and particularly configuration and management parts are a 
bit of a dog's breakfast.


>>> That other protocol can be just as VMS specific as Multinet's DECnet 
>>> over IP lines, I don't care. Design it, put it in VMS and perhaps then  
>>> we can talk about forgetting DECnet.
> 
> Sure.  Make IP FAL mostly system agnostic.  But able to deal with RMS 
> metadata.  VMS's HP TCPIP's FTP has this right.  If talking to another 
> VMS system it passes on RMS file attributes.  To any other system it's 
> just another FTP

Other than preferring security far past what FTP offers, I have no 
issues with this approach.      This is what I'd prefer to see.   This 
is part of getting rid of DECnet.   Of fully integrating IP into the 
distribution and into the OS environment, and there's more than a 
little work pending there well past the advent of VSI IP.

> .I don't want to see time spent on DECnet, more time on EDT nor more  
> time away from the port and the roadmap.
> 
> You know what's funny regarding EDT.  Not much time actually went into 
> EDT.  ...

This work certainly appears to undercut public statements and marketing 
statements from at least one of your senior folks.






-- 
Pure Personal Opinion | HoffmanLabs LLC