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

[Stephen Hoffman]

On 2016-10-06 19:18:22 +0000, Phillip Helbig (undress to reply said:

> In article <nt5stt$9c7$1 at dont-email.me>, Stephen Hoffman
> <seaohveh at hoffmanlabs.invalid> writes:
> 
>> DIRECTORY /FTP works fine without DECnet, and supports domain names.
>> Available since V6.2.
> 
> What about running a local procedure with input to or output to a remote disk?

Keep moving those goal posts.  You'll eventually get the results you 
want, after all.   If you work hard enough at this, you'll even find 
the last thing that OpenVMS and only OpenVMS can exclusively provide.

If I were on Unix, I'd use ssh and pipes, or a mount and SMB or NFS 
file shares here, or maybe netcat.   Maybe syslog, depending on what 
sort of logging was required.    Either write directly, or write to a 
simple server on the remote host.   Tools which work rather better than 
what OpenVMS and DCL can do here.

Preferably, I'd look to use a distributed scheduling and job management 
package or something akin to Apache Mesos, because — pragmatically — 
who cares what server the stuff is written on, where the server is even 
running, or what storage or what servers are involved or how the logs 
are routed?  This so long as the required results are acquired.   Even 
old and limited tools such as distcc can be a real eye-opener here for 
OpenVMS folks, for that matter.

The goal is to get rid of protocols and applications and tools that are 
wasting time and effort, or that have serious problems — DECnet being 
unauthenticated and unencrypted and generally unavailable on other 
platforms — dead, in the common parlance — and to get the IP stack and 
the tools forward to something approaching competitive.   Clinging to 
DECnet and OSI and the rest is not going to get new customers, new 
applications and new deployments.   Not enough to matter.

OpenVMS is a seriously painful experience — you yourself have been 
proving that over the past decade or two, when you repeatedly struggle 
with the platform, and when you have more than a few questions on 
something that should Just Work, but is either ill-documented, too 
cryptic, or part of documentation and examples and resources just 
aren't meeting your needs.

The more y'all keep trying to avoid changing your application code and 
avoiding changing the things that are broken, the harder you make it 
for VSI to fix things, to improve the platform, to work to secure the 
platform, and to work to address the requirements that new folks can or 
will have.   I listened to folks at the boot camp try to shut down some 
proposed cluster-related changes, and without even knowing what those 
changes might bring them.   Without even knowing what those changes 
were.    That approach is problematic.




-- 
Pure Personal Opinion | HoffmanLabs LLC