IA64 · x86-64 · Alpha coming
Today’s open source,
on OpenVMS.
Current GNU and open-source tools for OpenVMS, released in step with upstream: within days of a new release, not years. They are built natively with VSI C, tested on real systems and packaged as standard PCSI kits.
- 7
- ports released
- 2
- architectures
- 14
- PCSI kits
01 / Mission
Keeping OpenVMS in step with the rest of the industry.
OpenVMS still runs systems that are not allowed to stop: exchanges, railways, hospitals, factories. Its open-source toolbox has fallen behind, though. The GNU tools in the GNV kit are many releases old, and vendor kits for things like curl arrive on a vendor’s timetable rather than the community’s.
Our mission is to bring open-source and GNU projects onto OpenVMS in lock-step with their upstream releases. When GNU grep, curl or zlib ships a new version, the OpenVMS kit should follow within days and be built from the same signed source, with the same fixes and the same features.
We do this to show that OpenVMS can be a first-class home for modern software, and to give people running VMS today the same tools as everyone else.
Lock-step releases
Every kit is versioned after its upstream release, so
v3.12-vms3is GNU grep 3.12, VMS patch level 3.Thin, honest deltas
The repositories hold only our patches and VMS files. Upstream source always comes from the maintainer’s signed tarball.
Upstream first
VMS changes are guarded with
#ifdef __VMSand written so they can be sent upstream.
Yes, we use AI. Here is how.
Porting is mostly patient detective work: reading configure output, tracking down C run-time library quirks, rebuilding, and rerunning test suites. We use Anthropic’s Claude, through Claude Code, as a pair programmer for that work. It drafts patches, drives builds and tests on the VMS systems over SSH, and works through failures. This is how one maintainer can keep a whole family of ports current.
A human sets the direction and decides what ships. AI makes the work faster, but it does not replace the evidence that a port works.
- Built natively with VSI C and MMS on real IA64 and x86-64 OpenVMS systems
- Upstream test suites run on VMS. Every skipped test and expected failure is documented with its reason
- Source tarballs are verified against the maintainers’ signing keys
- Every change is a readable patch in a public repository
- A fixed kit always gets a new patch level. Version numbers are never reused
02 / Ports
The kits
Release details are read live from each project’s GitHub releases.
03 / Install
A few lines of DCL.
Download
Fetch the
.PCSIkit for your architecture (I64VMSorX86VMS) and the release’sSHA256SUMS, and check the kit against it.Restore the record format
A kit that passed through a non-VMS system loses its fixed-length record attributes. Put them back before installing.
Install with PCSI
Standard
PRODUCT INSTALL. Each kit includes a startup procedure and a per-user setup procedure that defines the commands.
Tip: under the default PARSE_STYLE=TRADITIONAL, DCL
changes the case of unquoted arguments, so -F arrives as -f. Quote options and
patterns (grep "-E" "Foo") or run $ SET PROCESS/PARSE_STYLE=EXTENDED.
04 / Method
From signed tarball to PCSI kit.
Each port uses the same pipeline, so a new upstream release usually means updating one version number, rebuilding and retesting. When upstream changes something that affects VMS, the build fails loudly instead of drifting quietly.
- 1
Fetch & verify
The upstream release tarball, checked against its SHA-256 and the maintainer’s GPG key.
- 2
Patch & overlay
A short, numbered patch series plus VMS-only files. Nothing upstream is edited by hand.
- 3
Configure
Upstream’s own
configure, with every compile test run by VSI C on the VMS system, or the project’s own VMS build where it has one. - 4
Build natively
MMS and VSI C on IA64 and x86-64. No cross-compilation.
- 5
Test
Upstream’s test suite under GNV, plus DCL smoke tests, batch-job tests and install checks.
- 6
Kit & release
PCSI kits under the ISSINOHO producer prefix, with SHA256SUMS, published on GitHub.
05 / Legacy
Fifty years of engineering that still runs.
Digital Equipment Corporation built minicomputers that put computing into labs, factories and offices, and an operating system that could keep running for years. Clustering, versioned files, a distributed lock manager and DCL’s readable commands were all part of VMS long before most systems had them. This project exists because that work still deserves current tools.
- 1957
Ken Olsen and Harlan Anderson found Digital Equipment Corporation in an old wool mill in Maynard, Massachusetts.
- 1977
The VAX-11/780 ships with VAX/VMS V1.0, designed to run on it.
- 1978
The VT100 arrives. Its escape sequences are still what every terminal emulator speaks.
- 1984
VAXclusters join several machines into one system with shared disks and a distributed lock manager.
- 1992
The 64-bit Alpha AXP arrives, and the operating system is now called OpenVMS.
- 1998
Compaq acquires Digital. In 2002, HP merges with Compaq.
- 2005
OpenVMS I64 brings VMS to Intel Itanium.
- 2014
VMS Software, Inc. takes over OpenVMS development.
- 2022
OpenVMS V9.2 runs on x86-64, on commodity servers and hypervisors.
- Now
Current GNU and open-source releases on OpenVMS, kept in lock-step with upstream. That’s us.
File versions
LOGIN.COM;3: every save keeps the previous version, decades before version control was common.
Clusters
Shared-everything clusters whose total uptime is measured in years, with rolling upgrades.
DCL
A command language you can read aloud: SET DEFAULT, DIRECTORY/SIZE, SHOW SYSTEM.
Architecture
Ported from VAX to Alpha, Itanium and x86-64, so the same code has outlived four instruction sets.
06 / Next
On the bench.
- in progressGNU m4: the next tool in the pipeline.
- plannedOpenVMS Alpha kits, alongside IA64 and x86-64.
- plannedNative VMS behaviour: VAR/VFC record formats and DCL wildcards.
- ongoingOffering our VMS patches upstream so that future releases need fewer of them.
Want a particular project ported? Open an issue and tell us what you need.