OpenVMX AA–OVMX2–TE

OpenVMX · Software Product Description · Version V0.6-13

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.6-13

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.

Log in with username SYSTEM, password MANAGER (or GUEST / GUEST)
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

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.

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. The path to building OpenVMX from inside OpenVMX.

06Cluster interop SCS · NISCA

An implementation of the VMScluster wire protocol, so OpenVMX nodes can join and serve storage as a cluster. In active research.

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
ArchitectureRoleNotesStatus
x86-64Node · primary target64-bit · dev host Supported
aarch64Node · first-class64-bit ARM Supported
Alpha / AXPNode · first-class64-bit DEC Alpha In progress
VAXNode · first-class32-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 among themselves over the SCS / NISCA wire, with an executive-resident lock manager and membership. Interoperating with a genuine VMS-family VAX — a real VAX joining and mounting OpenVMX-served storage — is the bar the work is driving to now.

What's real today

  • A real distributed lock manager over the SCS wire — cross-node locks.
  • Executive-resident membership: join, quorum, and SHOW CLUSTER.
  • MSCP-serves a genuine ODS-2 volume — the node's actual disk — over NISCA.
  • Multi-node OpenVMX clusters form in the lab.
  • Wire formats read off the wire, not vendor source.

In progress

  • A real VAX joining and mounting the served volume, byte-for-byte.

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. OpenVMX MSCP-serves a genuine ODS-2 volume — the node's actual disk, not a placeholder image staged to look served — and multi-node OpenVMX clusters form and hold together in the lab.

The remaining bar is interoperation with the real thing: a genuine VMS-family VAX joining the cluster and mounting OpenVMX-served storage byte-for-byte. That wire-fidelity work is in progress and not yet proven — the honest status, 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
ReleaseThemeState
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 →