Most of those a JIT recompilers, Mainframe code doesn't usually depend on instruction cycle timing to the level that say beam-racing game code does.
64 karma · joined March 26, 2024
But it's really just completely dead by now, which is a bummer as this leaves a large complexity gap between this and jumping ahead to just doing full Lambda+CDK/Serverless/Terraform setups.
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.
But normally OpenVMS clusters are not shared-memory systems, you get shared disks, locks, queues and access controls.
Bull released a MCP VM demo development kit, I tried really hard to set it up and write some simple ALGOL for it.
If anything it thought me to appreciate how MULTICS/UNIX (and aside the pdp10 world) gave us line oriented developer-focused interactive environments that don't make ones eyes bleed.
Somehow this seems like one of those idea's that many legacy-niche-OS developers imagine themselves in, it's old, uses little memory (and does little) so now it must be feasible as a embedded-OS, AmigaOS-oid developers imagined the same in the early 00's...
However about total amount of users I don't fully agree, there's significant deployments of VMS still around in the infrastructure and finance sectors. Although some very high profile customers have migrated away on to Linux using compatibility layers.
And within that subset there's customers that still have high performance requirements making them willing to invest in VMS on new hardware.
If you ran VMS on a GS1280 (64 Alpha CPU's, split into 2 32CPU partitions), then migrated to several generations of SuperDome's (Itanium) and your work-load is still scaling with your wider company demand, bare metal deployments on latest x86 hardware of VMS can perfectly make sense.