It is a rare day. Rosenkrantz has been resetting to firmware so we bought another VAX 4000-60 to try sort it out and this one is the cleanest we've ever seen.

@lcamtuf OpenVMS system security has data structure and API prefixes including NSA (Non-discretionary Security Auditing), KGB (Key Grant Block), and CIA (Compound Intrusion Analysis).

Your VAX in a Cloud is Ready - For many people of a certain age, the DEC VAX was the first computer they ever use... - https://hackaday.com/2025/01/28/your-vax-in-a-cloud-is-ready/ #retrocomputing #openvms #dec #vax #vms

...and so it begins, again.

Why am I not surprised that when a customer wants to try running #OpenVMS in the cloud, I somehow get dragged into it.

What’s next, someone making me get involved in an OS/2 offering someday? Commercial Minix offering? CP/M-86?

It would just be terrible if I had to spend my work hours on this instead of AI Startup-of-the-Minute. Terrible.

Two fucking years later - I STILL have not got a OpenVMS enthusiast license

And I have applied three times.

Hello and thank you for your interest in the VMS Software Community License Package! Here is how to use it:

Oh well, I can pivot from #QNX to #OpenVMS now ;).

Another day, another OpenVMS Community submission...

Third time I am trying, but still not accepted.

I wonder why..

VSI has reportedly ended their hobbyist community licensing program for OpenVMS Alpha and OpenVMS I64, and is restricting the OpenVMS x86-64 licensing to pre-built and pre-licensed downloads.

Which ends the general usefulness of older hardware platforms for OpenVMS hobbyists, and constrains what can happen on OpenVMS x86-64.

VSI have previously discontinued perpetual licenses for all platforms, and new versions for Alpha and for Itanium.

Outside of some guest images intended for training classes, it's all commercially-licensed SaaS on x86-64 from here on out.

OpenVMS file systems…

ODS-1: common RSX-11 file system, limited support on older OpenVMS.

ODS-2: OpenVMS traditional file system. Was updated from 9.3 to 39.39 filenames.

ODS-3: ISO-9660

ODS-4: ISO-9660 High Sierra

ODS-5: current OpenVMS extended file system

ODS-6: probably CFS, a file system as yet and probably forever unreleased.

Spiralog: a failed attempt at creating a log structured file system.

ANSI X3.27-1987 magtape file system. (-1987 fixed a Y2K bug, too.)

FAT: limited support via EFI$CP, or via other add-on tools.

The EXCHANGE utility adds a few PDP-11 formats.

Gaps in OpenVMS file system support exist: FAT, SMB (yeah, not technically a file system), NTFS, common ISO-9660 extensions, UDF, and accessing any volumes larger than two tebibytes.

"Effective February 15, 2024, Google Groups will no longer support new Usenet content. Posting and subscribing will be disallowed, and new content from Usenet peers will not appear. Viewing and searching of historical data will still be supported as it is done today."

Google have been having massive spam problems with Google Groups spam, and it seems Google have decided to fix the spam problem by discontinuing the existing Google Groups usenet peering.

The comp.os.vms newsgroup and other groups have been largely or entirely unusable via Google Groups (<https://groups.google.com/g/comp.os.vms>) for a while now, and the folks administering usenet servers have been dealing with a flood of spam posted from Google Groups.

How long the historical usenet data—what was once the Dejanews usenet archives—will remain available at Google is unclear. I'd hope Internet Archive can get a copy, if Google decides to discontinue that archive.

Yes, usenet still exists, is still in use, and the archives of various newsgroups are still useful.

#Google #GoogleGroups #OpenVMS #history #History #Retrocomputing #retrocomputing #usenet #usenetnews #nntp #KilledByGoogle @killedbygoogle

Many problems have simple and easy-to-understand answers. Those answers are wrong.

A trip through Unix and its APIs and philosophy, with side trips including C and tooling, asynchronous and blocking designs, Windows and OpenVMS, and communities and the inherent problems of meritocracy.

“We’re not on a PDP-11 any more, Toto.”

Benno Rice, from 2020:

https://www.youtube.com/watch?v=9-IWMbJXoLM

Other areas (not mentioned) where thinking can block better app and API designs involves layering, including the OSI networking stack, and traditional file system layering and designs such as ZFS.

The following paper on the problems with non-scalable locking designs certainly explains some of the empirical (and app-dependent) behaviors observed with OpenVMS on larger Alpha and Itanium multiprocessors.

This is mostly OpenVMS on Alpha and Itanium multiprocessors, and now on x86-64 multicore designs, as VAX 9000 (Aridus) topped out at four (scalar) processors, and other later (and much more affordable, as compared with Aridus) VAX multiprocessors got to six or maybe eight processors.

In decades past, app performance on OpenVMS multiprocessors fell off pretty quickly starting around eight processors (or eight cores, more recently).

With the work that went into OpenVMS itself to break up spinlocks and to reduce related synchronization overhead, and with apps becoming more cognizant of NUMA hardware (where available), maintaining app performance on sixteen processors (cores) became more commonly feasible.

OpenVMS spinlocks are a somewhat simpler design than the ticket spinlocks Linux is currently using, too.

But somewhere along the path of adding more processors to scale app performance, Cache Coherency and Amdahl’s Law do come to visit, and performance craters.

https://people.csail.mit.edu/nickolai/papers/boyd-wickizer-locks.pdf