Nearly 30 years after its initial release for the VAX-11/780, it is safe to say that OpenVMS has achieved these initial goals and more. Today, OpenVMS runs on the 64-bit Alpha and IA-64 platforms in addition to the original 32-bit VAX. It can also be run under emulators for the VAX and Alpha architectures on the IA-32 platforms using Charon-VAX, Charon-Alpha, and SIMH emulators under both Linux and Windows. The architectural leverage that enabled the engineering team at Digital Equipment Corporation (now HP) to implement a mainframe-class system in an unprecedented short time has allowed OpenVMS to assimilate two additional generations of architectures, define and pioneer OpenVMS clusters, and become the Gold Standard for reliability and integrity. By designing a system for corporate datacenters, the design also provides the same capabilities in a desktop environment.
For many years, it has been routine for OpenVMS systems to run for hundreds of days at a time, in full production without restarts. OpenVMS clusters, which are composed of multiple OpenVMS processors sharing a file system, have reported uptimes measured in decades, across system updates, CPU changes, and mass storage reconfigurations and upgrades.
In addition to the original line mode interface, the DECwindows package, which is part of the integrated distribution, provides the Open Software Foundation MOTIF desktop, common to many workstations.
From its inception in 1975, OpenVMS has been a system that has been strongly architected, with a core set of fundamental concepts. These concepts include:
- Logical Names
- Event-Driven Scheduling
- Common Record Management (including implicit Record Locking)
- Cross-Language Run Time and Calling Standard
- System Integrity
These core concepts have provided a framework that has allowed OpenVMS to seamlessly evolve in directions inconceivable at the outset, including OpenVMS Clusters (1983), workstations, and secure computing. OpenVMS was the first system to be certified by the US National Computer Security Center at the C2 level, in 1986. OpenVMS has been able to work in both timesharing, network server, and realtime environments, with no special adaptations.
OpenVMS security has a well deserved reputation for security. A team of users led by the late John Wisniewski took an AlphaServer to DefCon9, where the system was rated as "Cool and Unhackable", despite the fact that the hacker community was permitted full use of non-privileged accounts. It is also reported that the OpenVMS team was invited to never return to DefCon (reportedly a rule change was instituted to require the use of an Intel-based architecture).
The OpenVMS event processing model, Asynchronous System Traps (ASTs), is also dramatically different from the signal mechanism commonly used on *IX. ASTs are a queue of serial events, First-In, First-Out within each individual process, with one queue per access mode (OpenVMS uses four access modes, Kernel, Executive, Supervisor, and User). An AST is non-preemptable within an access mode within a process. The number of these lightweight events that can be pending at any time is governed by a per-process quota that is set on a per-user basis in the User Authorization File. It is thus possible for an OpenVMS process to have hundreds of pending events based on IO, locking, or time, without any need for the types of events to be defined in advance. ASTs can also be declared from within a user-program or library, allowing libraries to implement the same semantics as the operating system's facilities (see OpenVMS-ALPHA/VAX Asynchronous System Trap Internals for a more complete discussion).
Another unique facility of OpenVMS is the Logical Name facility. In its most basic form, the logical name facility provides a four level (System, Group, Job, and Process) hierarchy. It is possible to add levels to this hierarchy on a per-process, job, or group basis. Logical name translation is iterative and recursive, with each individual translation using the hierarchy of logical name tables in order to resolve translations.
It is thus possible to completely sever connections between the physical environment and the logical environment at each of the levels, potentially presenting a different logical environment to each user or job. An example of how this can be used may be found in the OpenVMS Technical Journal paper Inheritance based Environments for OpenVMS Systems and OpenVMS Clusters . This capability allows OpenVMS environments to serve thousands, or tens of thousands of users on a single system or OpenVMS cluster, each with a logical environment tailored to their own requirements or permissions.
- "OpenVMS, 1/2"
- "OpenVMS, 2/2"