OpenVMX · Software Product Description · Version V0.7-15

DCL, RMS, and VMS from scratch on the Linux and NetBSD kernels.

The two panels below run OpenVMX in your browser: on x86_64 (QEMU compiled to WebAssembly) and on a MicroVAX 3900 (a 1977 VAX, emulated). Same OS on both — same DCL, same RMS, same executive.

OpenVMX OVMX · x86_64 · console · snapshot V0.7-15

OVMX01 · HALTED · READY TO BOOT

One-time ~105 MB download, cached after the first visit. Resumes a pre-booted OpenVMX machine in a few seconds. Emulated, so interaction is slow.

The amber CRT styling is OpenVMX presentation, not VMS-authentic. The guest resumes from a snapshot under QEMU compiled to WebAssembly; TCG emulation is slow. Single node.

OpenVMX OVMX/VAX · MicroVAX 3900 · console · disk V0.7-15

OVMX/VAX · HALTED · READY TO BOOT

A real MicroVAX 3900 (KA655) emulated in your browser, booting the same OpenVMX. Cold boot to login takes ~4 minutes — it's the 1977 ISA, live. ~9 MB streamed.

Boots and signs itself in as SYSTEM to a live DCL $; the prompt is then interactive.

PCjs KA655 emulator (JS), running OpenVMX/VAX over a NetBSD-VAX kernel — the same OS as the x86_64 panel. It boots and logs in to the DCL $. Emulated, so it's slow. Single node.

View the source on GitHub → or build and boot it yourself

Built from the published specifications and observed behavior.

ShellDCL · RMS · SYS$

Executivevms.ko · /dev/vms

Runtimeboots on QEMU

Licensefree & open source

Build and boot it yourself → · github.com/3dl-dev/vms

1.0

From the syscall layer to the shell

OpenVMX rebuilds a whole operating system as its own software: the command language, the file system, the system services, the executive. All of it implemented from public specifications and released as open source.

How it's built

Implemented from public documentation and observed behavior.
Original, independent code.
Its own userland: no libc, no ld.so.
Where the specs stop, OpenVMX makes its own choices and labels them.
Open source, readable end to end.

The classic operating-system layers are here as their own libraries, built in dependency order: the freestanding syscall floor, process control blocks with ASTs and event flags, the SYS$ / LIB$ / STR$ run-time, logical-name management, an ODS-2 file system, and Record Management Services on top.

Above them sits DCL, the Digital Command Language shell. It behaves the way longtime users expect rather than like bash, down to $ prompts, SHOW verbs, and structured file specifications. The keyboard behaves the same way: a VMS terminal driver in the executive holds what you type ahead until DCL reads it, and handles CTRL/Y, CTRL/C, CTRL/T and CTRL/O itself.

Underneath, a kernel module (vms.ko) provides the executive: locks, event flags, ASTs, and access modes as shared system state, reached from userspace through /dev/vms. When the executive is absent, services fail honestly with SS$_NOSUCHDEV. They never fake per-process success.

2.0

System components

Each facility is a discrete library or module. You can read it, build it, and test it on its own.

01System services & RTL SYS$ / LIB$ / STR$

The run-time: descriptors, condition handling, logical names, event flags, ASTs. Every API returns a status code, where odd means success.

02The DCL shell DCL

Lexer, parser, executor, and built-in verbs for the Digital Command Language. External utilities dispatch the same way the shell does.

03Records & files RMS · ODS-2

FAB / RAB / NAM / XAB record management over a genuine Files-11 ODS-2 volume, served by the executive file ACP.

04Kernel executive vms.ko

The distributed lock manager, event flags, ASTs, and access modes as shared system state, reached through /dev/vms.

05Native toolchain IMGACT · LINK

An image activator and linker with symbol-vector activation. Programs linked on a real VMS Alpha system already run unchanged for a first set of services, and GCC's compiler runs on OpenVMX/Alpha: the path to building OpenVMX from inside OpenVMX.

06Cluster interop SCS · NISCA

An implementation of the VMScluster wire protocol. A real VAX running VMS V7.3 counts OpenVMX nodes as cluster members today; storage served across a mixed cluster is in active development.

3.0

Architectures, and the cluster world

OpenVMX runs as a node on modern 64-bit silicon and, over a NetBSD-VAX substrate, on the VAX itself — it boots to a DCL prompt on all of them. The VAX is also the reference platform OpenVMX is built to interoperate with: the cluster world it is designed to join. Read the axis as a role, not just a chip.

Table 3–1 · Architecture & interoperability matrix
Architecture	Role	Notes	Status
x86-64	Node · primary target	64-bit · dev host	Supported
aarch64	Node · first-class	64-bit ARM · release download since V0.7-11	Supported
Alpha / AXP	Node · first-class	64-bit DEC Alpha	In progress
VAX	Node · first-class	32-bit DEC VAX · NetBSD substrate	In progress

4.0

Clusters & interoperability

OpenVMX does not emulate a cluster. It implements the machinery: OpenVMX nodes form a real cluster over the SCS / NISCA wire, with an executive-resident lock manager and membership, and a genuine VAX running VMS V7.3 accepts them as members. You can watch one form in the three-node cluster demo: two OpenVMX nodes and a V7.3 VAX, all in your browser.

What's real today

A real distributed lock manager over the SCS wire — cross-node locks.
Executive-resident membership: join, quorum computation, and SHOW CLUSTER.
A real VAX running VMS V7.3 counts OpenVMX nodes as cluster members.
In the lab, a running workload moved from a real VAX to an OpenVMX node, taking over its locks while the cluster stayed up.
An OpenVMX node founds a cluster and a real VAX joins it; a node that boots last is admitted through any member.
Clusterwide logical names: OpenVMX applies the other members' changes and pulls the cluster's logical-name table when it joins late.
Wire formats read off the wire, not vendor source.

In progress

Reading and serving genuine ODS-2 volumes across a mixed cluster over MSCP.
Taking over the lock trees a departing VAX hands on (remastering).
Originating clusterwide logical names from an OpenVMX node.
The browser cluster demo is not yet reliable for every visitor. V0.7-15's visitor gate ran each of eight join orders once on the first release candidate and twice on the tagged commit. On the tagged commit all eight orders reached a DCL prompt on both OpenVMX nodes in both runs, with no VAX bugcheck. On the candidate, one order with a throttled CPU left the OpenVMX/VAX node at its console prompt, because the page answered the console's terminal query late and the reply swallowed the first letter of the boot command. The page now answers on the emulated machine's own clock. V0.7-15 also fixes a cluster state transition that could make the real VAX bugcheck (LOCKMGRERR) in some join orders, a fault present since V0.7-12. On the merged fix, 80 of 80 runs across two join orders formed the cluster. A rare console-input wedge, where a node stopped taking input after a login timeout, did not appear in these runs but has not been root-caused.

The cluster machinery is real, not staged. An executive-resident lock manager grants and releases locks across nodes over the SCS wire; membership, quorum, and SHOW CLUSTER are served from executive state.

Mixed clusters work today. A genuine VAX running VMS V7.3 accepts OpenVMX nodes as members, and in the lab a workload has moved from a VAX to an OpenVMX node, its locks and records carrying on without a gap while quorum held. An OpenVMX node can also found the cluster a VAX then joins. What remains is the rest of that handover: taking over the lock trees a departing VAX passes on, and storage served across the cluster over MSCP. That work is in progress, tracked on the roadmap.

The wire formats were worked out by watching a reference VAX and Alpha cluster and reading the public documentation, never from vendor source.

5.0

The compatibility surface

Every VMS surface, and how far OpenVMX has got with each one, including the gaps. It tracks each facility (the DCL verbs, RMS, the system services, the executive, clustering) and marks where OpenVMX is complete, where it is partial, and where it is not there yet.

Open the compatibility surface →

6.0

Roadmap & releases

OpenVMX ships on a tag cadence. Each milestone is a verifiable end state, not a wish list. The full roadmap and the live release status are regenerated from the project's own work board each checkpoint.

Recent releases

Loading recent releases…

Table 6–1 · Milestone ladder
Release	Theme	State
Loading the milestone ladder…

7.0

Build and boot

One runtime target: the real-kernel / QEMU path. Clone the source, build the bootable image, and bring up an OpenVMX VM.

terminalsh

# clone the source
$ git clone https://github.com/3dl-dev/vms.git && cd vms

# build the bootable distribution (all deps containerized)
$ docker build -f Dockerfile.bootable -o dist .

# boot OpenVMX as a QEMU VM; vms.ko is the executive via /dev/vms
$ ./distro/boot/run-qemu.sh dist/vmlinuz dist/initramfs-ovmx.cpio.gz

# at the login banner:  SYSTEM / MANAGER
$ SHOW SYSTEM

Prefer to work at the library level? A standard cmake -B build -DBUILD_TESTS=ON tree builds the shared libraries and the test suite with ctest. Full instructions live in docs/building.md.

Read the source on GitHub →