In its initial concept, OpenVMS (then VAX/VMS) sought to provide the functionality and capabilities of a mainframe-class system at a small fraction of the size and cost, while at the same time providing higher levels of reliability and integrity. These goals were achieved by what has become OpenVMS’ hallmark, an
emphasis on integrity and architectural leverage. Note: This is an entry to our OS Contest.
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
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.
For example, using Figure 1, the value of a logical name, for example, the translation of DISK$SCRATCH varies depending upon which process context the name is translated:
|Process ID||Translation of DISK$SCRATCH|
Alternatively, the translation of the logical name MASTERFILES also varies by which process context the translation is performed in:
|Process ID||Translation of MASTERFILES|
|Figure 1. Different Logical Name environments for different users and groups (from Inheritance based Environments for OpenVMS Systems and OpenVMS Clusters, Gezelter, February 2004)|
The integration of the Logical Name facility with the Record Management Services (referred to as “RMS”) Open facility yields a far more powerful mechanism than the environmental parameters used on *IX and Windows. The filename supplied to RMS may include an integral logical name, which will be automatically translated. For example, a file PHONELIST.DAT located in the directory pointed to by the MASTERFILES logical name would be specified as MASTERFILES:PHONELIST.DAT.
RMS is another area where OpenVMS has taken a fundamentally different architectural path than *NIX and Windows. RMS is a universal toolkit that defines a variety of file types (sequential, relative, indexed) and provides defined, automatic ways for programs to access the contents of a file without the need for awareness of the underlying file format. Thus, the TYPE utility produces reasonable results regardless of the underlying file type. Using TYPE on an index file yields the actual data records in order by their primary key without anything more than a simple OPEN. In modern terminology, OpenVMS RMS provides an object-oriented toolkit for managing files. However, RMS, which was part of the original VAX/VMS design, predates the popularity of the object-oriented paradigm by at least a decade.
Similarly, the shareable library facility, which on a system-wide level is a technology fundamental to the use of the Common Runtime Library, is fully available to normal users and provides the ability to implement extremely flexible environments in a simple, yet powerful manner. A more complete presentation of the use of shareable libraries may be found in presentations from the 1996 Spring DECUS symposium: OpenVMS Shareable Libraries: An Implementor’s Guide and Case Studies in OpenVMS Shareable Libraries.
OpenVMS is also notable in that it uses neither an open-source, nor a closed-source model. Instead, the OpenVMS model is better described as visible-source. Since the first release of OpenVMS in 1978, the overwhelming majority of the source listings have been available for purchase at nominal cost, originally on microfiche, presently on CDROM. The interfaces needed to write device drivers and other privileged extensions of the operating system have been well documented for the entire life of OpenVMS.
Since 1997, OpenVMS has been available for free for personal, non-commercial use. This program, known as the Hobbyist program has issued over 644,000 licenses. Details about the Hobbyist program are available at http://www.OpenVMSHobbyist.org. Unrestricted commercial licenses are available with the actual price depending upon the architecture and size of the system. Licenses are also available to developers under Hewlett Packard‘s Developer and Solution Partner Program (DSPP).
Now approaching its 30th anniversary, OpenVMS continues to seamlessly add new capabilities, while continuing the hallmark features that have made it the first choice for many mission-critical applications, across the full spectrum of computing from desktop to datacenter.
About the author:
Robert Gezelter, CDP, Software Consultant,
guest lecturer and technical facilitator has more than 25 years of international consulting experience in private and public sectors. Mr. Gezelter is a regular guest speaker at technical conferences world-wide such as HPETS (formerly DECUS).
He has worked extensively in OpenVMS since its initial release as VAX/VMS in 1978. He consults extensively on computer architectures, operating systems, APIs, networks, security, and related matters.
Among his published work are articles appearing in Network World, Open Systems Today, Digital Systems Journal, Digital News,
The OpenVMS Technical Journal, and Hardcopy. Mr. Gezelter also
writes a Column and serves as a Contributing Editor on
www site serving the OpenVMS community. He is also a contributor to the
Computer Security Handbook, 4th Edition
(Wiley, 2002) and the “OpenVMS Security” and “Internet E-Mail Architecture” chapters of the
Handbook of Information Security (Wiley, 2005).
Mr. Gezelter can be reached via his firm’s www site at http://www.rlgsc.com.