I had been interested in this, but the community program was so restrictive and half-baked that I never got involved.
I'm not surprised that it failed.
I'm not surprised that it failed.
In the exclusive camp we have:
- cross cluster shared memory
In the can be replicated in user land category we have - logicals, env vars with an inheritance from cluster level to process level
- distributed locks
Those two features make something like etcd pointless
- a cross cluster file system that makes nfs look like the hack it is
And finally Linux has finally caught up and passed with iouring, but VMS has had an excellent completion based io model since the early 90s.
Don't you need specialised hardware for that?
But normally OpenVMS clusters are not shared-memory systems, you get shared disks, locks, queues and access controls.
And I think perhaps you are overselling also the level at which VMS supports some of these and the performance there-of. Shared memory clustering I don't think is really a thing on VMS actually, unless you mean application state sharing over shared files on disk (which can be cached).
A typical VMS clustered application might look something like this:
Applications runs as multiple separate processes distributed across cluster nodes that access shared disk and queues.
On shared disks you'll have shared persistence used by all the nodes of the applications.
The persistence can be in files managed with RMS (Record Management Services, think 80's sqlite)
The distributed lock manager handling locking at the record level (which can be actual records or text-lines in the file)
Said application might distribute work events around it through OS Queue's that are also shared across the cluster allowing for task distribution across a cluster.
And all of this is fronted by a terminal multiplexer that will round-robin incoming sessions (because most of these systems will be TUI kind of things) to a random node in the cluster.
All of the above are built-in OS services, it's the ultimate monolith :)
.... Now if you equate that to some typical enterprise system this quickly maps across to something like:
Fronted by a http proxy bouncing requests to pods.
Application distributed across pods on K8 Cluster.
Clustered SQL for persistence layer and record services.
Kafka/RabbitMQ for your queue's for event distribution.
All of those services will be significantly more feature rich, performant and if correctly deployed more resilient than a VMS cluster too.
I suppose if I knew the right person I could email them and get access, but I've seen at least one public statement (on their forums, maybe? or twitter?) saying there's a long line because it takes time and manual effort to set up the accounts, which is kind of the saddest thing ever. I guess I'm content to wait in line (forever?).
No, it's community's fault! /s
I don't know what their expectations were- most people using the community license probably were happy enough to let their old hobby hardware chug along, and didn't feel the need to write articles or publish software. Looks like they actually released a "partial OpenVMS git" implementation.
And the solution for this is, obviously, not force them to brick their toys, but to get more people playing.
Lots of people pay decent money for emulations of ancient hardware in order to experience computing the way it was. Just look at the people running their PiDP's with their ancient software.
I'd totally run DecWindows as a daily driver if I could. It has X and SSH. What else do I need?