OpenVMS


OpenVMS is a multi-user, multiprocessing virtual memory-based operating system designed for use in time-sharing, batch processing, and transaction processing. It was first released by Digital Equipment Corporation in 1977 as VAX/VMS for its series of VAX minicomputers. OpenVMS also runs on DEC Alpha systems, the Itanium-based HPE Integrity family of computers, and it can run natively on select x86-64 systems as of 2020. OpenVMS is a proprietary operating system, but source code listings are available for purchase.
The name VMS is derived from virtual memory system, for one of its principal architectural features. When process priorities are suitably adjusted, it may approach real-time operating system characteristics. The system offers high availability through clustering and the ability to distribute the system over multiple physical machines. This allows the system to be tolerant against disasters that may disable individual data-processing facilities.
OpenVMS contains a graphical user interface, a feature that was not available in earlier original VAX/VMS releases. Prior to the introduction of DEC VAXstation systems in the 1980s, the operating system was used and managed from text-based terminals, such as the VT100, which provide serial data communications and screen-oriented display features. Versions of VMS running on DEC Alpha workstations in the 1990s supported OpenGL and Accelerated Graphics Port graphics adapters.
Enterprise-class environments typically select and use OpenVMS for various purposes including mail servers, network services, manufacturing or transportation control and monitoring, critical applications and databases, and particularly environments where system uptime and data access is critical. System up-times of more than 10 years have been reported, and features such as rolling upgrades and clustering allow clustered applications and data to remain continuously accessible while operating system software and hardware maintenance and upgrades are performed, or when a whole data center is destroyed. Customers using OpenVMS include banks and financial services, hospitals and healthcare, network information services, and large-scale industrial manufacturers of various products.

History

Origin and name changes

In April 1975, Digital Equipment Corporation embarked on a hardware project, code named Star, to design a 32-bit virtual address extension to its PDP-11 computer line. A companion software project, code named Starlet, was started in June 1975 to develop a totally new operating system, based on RSX-11M, for the Star family of processors. These two projects were tightly integrated from the beginning. Gordon Bell was the VP lead on the VAX hardware and its architecture. Roger Gourd was the project lead for the Starlet program, with software engineers Dave Cutler, Dick Hustvedt, and Peter Lipman acting as the technical project leaders, each having responsibility for a different area of the operating system. The Star and Starlet projects culminated in the VAX 11/780 computer and the VAX-11/VMS operating system. The Starlet name survived in VMS as a name of several of the main system libraries, including STARLET.OLB and STARLET.MLB.
Over the years the name of the product has changed. In 1980 it was renamed, with version 2.0 release, to VAX/VMS. With the introduction of the MicroVAX range such as the MicroVAX I, MicroVAX II and MicroVAX 2000 in the mid-to-late 1980s, DIGITAL released MicroVMS versions specifically targeted for these platforms which had much more limited memory and disk capacity; e.g. the smallest MicroVAX 2000 had a 40MB RD32 hard disk and a maximum of 6MB of RAM, and its CPU had to emulate some of the VAX floating point instructions in software. MicroVMS kits were released for VAX/VMS 4.4 to 4.7 on TK50 tapes and RX50 floppy disks, but discontinued with VAX/VMS 5.0.
In 1991, VMS was renamed to OpenVMS as an indication for its support of "open systems" industry standards such as POSIX and Unix compatibility, and to drop the hardware connection as the port to DIGITAL's 64-bit Alpha RISC processor was in process. The OpenVMS name first appeared after the version 5.4-2 release.

Port to DEC Alpha

The VMS port to Alpha resulted in the creation of a second and separate source code libraries for the VAX 32-bit source code library and a second and new source code library for the Alpha 64-bit architectures. 1992 saw the release of the first version of OpenVMS for Alpha AXP systems, designated OpenVMS AXP V1.0. The decision to use the 1.x version numbering stream for the pre-production quality releases of OpenVMS AXP caused confusion for some customers and was not repeated in the next platform port to the Itanium.
In 1994, with the release of OpenVMS version 6.1, feature parity between the VAX and Alpha variants was achieved. This was the so-called Functional Equivalence release, in the marketing materials of the time. Some features were missing however, e.g. based shareable images, which were implemented in later versions. Subsequent version numberings for the VAX and Alpha variants of the product have remained consistent through V7.3, though Alpha subsequently diverged with the availability of the V8.2 and V8.3 releases.
In November 2017, V8.4-2L1 was released for Alpha platform.

Port to Intel Itanium

In 2001, just prior to its acquisition by Hewlett-Packard, Compaq announced the port of OpenVMS to the Intel Itanium architecture. This port was accomplished using source code maintained in common within the OpenVMS Alpha source code library, with conditional and additional modules where changes specific to Itanium were required. The OpenVMS Alpha pool was chosen as the basis of the port as it was significantly more portable than the original OpenVMS VAX source code, and because the Alpha source code pool was already fully 64-bit capable. With the Alpha port, many of the VAX hardware-specific dependencies had been previously moved into the Alpha System Reference Manual firmware for OpenVMS. Features necessary for OpenVMS were then moved from SRM into a component of the OpenVMS kernel named the Software Interrupt Services.
Unlike the port from VAX to Alpha, in which a snapshot of the VAX code base circa V5.4-2 was used as the basis for the Alpha release and the 64-bit source code pool then diverged, the OpenVMS Alpha and I64 versions of OpenVMS are built and maintained using a common source code library and common tools. The core software source code control system used for OpenVMS is the VMS Development Environment.
Two pre-production releases, OpenVMS I64 V8.0 and V8.1, were available on June 30, 2003 and on December 18, 2003. These releases were intended for HP organizations and third-party vendors involved with porting software packages to OpenVMS I64.
The following are recent OpenVMS I64 releases:
When VMS Software Inc. announced that they secured the rights to develop the OpenVMS operating system from HP, they also announced their intention to port OpenVMS to the standard x86-64 architecture. The porting effort ran concurrently with the establishment of the company, as well as the development of VSI's own Itanium and Alpha releases of OpenVMS 8.x.
The x86-64 port is targeted for specific servers from HPE and Dell, as well as certain virtual machine hypervisors. Initial support was targeted for KVM and VirtualBox. Support for VMware was announced in 2020, and Hyper-V has been described as a future goal for VSI.
The x86-64 port is built from the same codebase as the Alpha and Itanium architectures, using conditional compilation to manage the architecture-specific code needed to support the x86-64 platform. As with the Alpha and Itanium ports, the x86-64 port made some changes to simplify porting and supporting OpenVMS on the new platform:
The first boot was announced on the 14th May 2019. This involved booting OpenVMS on VirtualBox, and successfully running the DIRECTORY command. Later in 2019, the first "real boot" was announced - this consisted of the operating system booting in a completely standard manner, a user logging into the system, and running the DIRECTORY command. In May 2020, the 9.0 Early Access Release was made available to certain customers. This contains the full OpenVMS operating system running in a VirtualBox VM with certain limitations - most significantly, little to no layered products are available, and code can only be compiled for x86-64 using cross compilers which run on an Itanium-based OpenVMS systems.

Major release timeline

Features

OpenVMS offers many features that are now considered standard requirements for any high-end server operating system. These include:
The first graphical user interface was added to VMS to support workstation applications on VAXstation hardware. Over the years, VMS has gone through a number of different GUI toolkits and interfaces:
OpenVMS supports clustering, where multiple systems share disk storage, processing, job queues and print queues, and are connected either by proprietary specialized hardware or an industry-standard LAN. A LAN-based cluster is often called a LAVc, for Local Area Network VMScluster, and allows, among other things, bootstrapping a possibly diskless satellite node over the network using the system disk of a bootnode.
VAXcluster support was first added in VMS version 4, which was released in 1984. This version only supported clustering over CI. Later releases of version 4 supported clustering over LAN, and support for LAVC was improved in VMS version 5, released in 1988.
Mixtures of cluster interconnects and technologies are permitted, including Gigabit Ethernet, SCSI, FDDI, DSSI, CI and Memory Channel adapters.
OpenVMS supports up to 96 nodes in a single cluster, and allows mixed-architecture clusters, where VAX and Alpha systems, or Alpha and Itanium systems can co-exist in a single cluster.
Unlike many other clustering solutions, VMScluster offers transparent and fully distributed read-write with record-level locking, which means that the same disk and even the same file can be accessed by several cluster nodes at once; the locking occurs only at the level of a single record of a file, which would usually be one line of text or a single record in a database. This allows the construction of high-availability multiply redundant database servers.
Cluster connections can span upwards of, allowing member nodes to be located in different buildings on an office campus, or in different cities.
Host-based volume shadowing allows volumes to be shadowed across multiple controllers and multiple hosts, allowing the construction of disaster-tolerant environments.
Full access into the distributed lock manager is available to application programmers, and this allows applications to coordinate arbitrary resources and activities across all cluster nodes. This includes file-level coordination, but the resources and activities and operations that can be coordinated with the DLM are completely arbitrary.
OpenVMS V8.4 offers advances in clustering technology, including the use of industry-standard TCP/IP networking to bring efficiencies to cluster interconnect technology. Cluster over TCP/IP is supported in OpenVMS version 8.4, which was released in 2010.
With the supported capability of rolling upgrades and multiple system disks, cluster configurations can be maintained on-line and upgraded incrementally. This allows cluster configurations to continue to provide application and data access while a subset of the member nodes are upgraded to newer software versions.

File system

OpenVMS has a very feature-rich file system, with support for stream and record-oriented IO, access control lists, and file versioning. The typical user and application interface into the file system is via the Record Management Services or RMS.

Timekeeping

OpenVMS represents system time as the 64-bit number of 100 nanosecond intervals since the epoch. The epoch of OpenVMS is midnight preceding November 17, 1858, which is the start of Modified Julian Day numbering. The clock is not necessarily updated every 100 ns; for example, systems with a 100 Hz interval timer simply add 100000 to the value every hundredth of a second. The operating system includes a mechanism to adjust for hardware timekeeping drift; when calibrated against a known time standard, it easily achieves an accuracy better than 0.01%. All OpenVMS hardware platforms derive timekeeping from an internal clock not associated with the AC supply power frequency.
While the system is shut down, time is kept by a Time-of-Year hardware clock. This clock keeps time to a lower resolution and generally, a lower accuracy. When the system is restarted, the VMS 64-bit time value is recomputed based on the time kept by the TOY clock and the last recorded year.
The 100 nanosecond granularity implemented within OpenVMS and the 63-bit absolute time representation should allow OpenVMS trouble-free time computations up to 31-JUL-31086 02:48:05.47. At this instant, all clocks and time-keeping operations in OpenVMS will suddenly fail, since the counter will overflow and start from zero again.
Though the native OpenVMS time format can range far into the future, applications based on the C runtime library will likely encounter timekeeping problems beyond January 19, 2038 due to the Year 2038 problem. Many components and applications may also encounter field-length-related date problems at year 10000.

Programming

Among OpenVMS's notable features is the Common Language Environment, a strictly defined standard that specifies calling conventions for functions and routines, including use of stacks, registers, etc., independent of programming language. Because of this, it is possible and straightforward to call a routine written in one language from another, without needing to know the implementation details of the target language. OpenVMS itself is implemented in a variety of different languages, and the common language environment and calling standard supports freely mixing these languages, and Ada, PL/I, Fortran, BASIC, and others. This is in contrast to a system such as Unix, which is implemented nearly entirely in the C language.
The common language programming environment is described in the OpenVMS Calling Standard and the OpenVMS Programming Concepts manuals. This provides mixed-language calls, and a set of language-specific, run-time library, and system service routines. The language calls and the RTLs are implemented in user-mode shareable images, while the system services calls are generally part of the operating system, or part of privileged-mode code. This distinction between languages and RTLs and system services was once fairly clean and clear, but the implementations and specifics have become rather more murky over the years.
Macro32 is available within and integrated into OpenVMS. BLISS compilers are available for download, as are various ports of Perl, PHP, Ruby and other languages. Java SE is provided with OpenVMS, with OpenJDK available for the Integrity platform. C, Fortran and other languages are commercial products, and are available for purchase.
Various utilities and tools are integrated, as are various add-on languages and tools.
Many programming examples are available via the OpenVMS FAQ.

Debugging

The VMS Debugger supports all DEC compilers and many third party languages. It allows breakpoints, watchpoints and interactive runtime program debugging either using a command line or graphical user interface.

Standard streams

In a manner similar to Unix, VMS defines several standard input and output streams with these logical names:
SYS$INPUT - Standard input. Used interactively, this represents the terminal keyboard. Used in a batch file, it is batch file lines not preceded with a $ symbol, or specified as an input deck using the DECK command.
SYS$OUTPUT - Standard output. Used interactively, this is the terminal display. Used in a batch file, it outputs to the screen or to the log file when run noninteractively.
SYS$ERROR - Standard error. Used interactively, this is the terminal display. In a batch file, it is the screen display, or to the log file if run interactively, or in the special case of RUN /DETACH, to the output file or device specified with the /ERROR= parameter.
SYS$COMMAND - Does not have a direct analogue in the Unix model. Used interactively, it will read from the terminal. Used in a batch file when run interactively, it will read from the terminal. Used in a batch file run noninteractively, it will read from the SYS$INPUT stream, otherwise it will read nothing and return end of file.

Security

OpenVMS provides various security features and mechanisms, including security identifiers, resource identifiers, subsystem identifiers, ACLs, and detailed security auditing and alarms. Specific versions evaluated at DoD NCSC Class C2 and, with the SEVMS security enhanced services support, at NCSC Class B1, per the NCSC Rainbow Series. OpenVMS also holds an ITSEC E3 rating./ Passwords are hashed using the Purdy Polynomial.

Vulnerabilities

A 33-year-old vulnerability in VAX/VMS and Alpha OpenVMS was discovered in 2017. While it affected the defunct VAX and Alpha platforms, it was relatively inconsequential on the then-current Itanium platform. The CVE number is.
Since old production hardware or emulated systems were at risk, patches were made available for the affected platforms—except for the by then unsupported VAX platform for which only a workaround was made available that involved removing privileges to the CDU utility. On an unpatched Itanium system, the attack resulted in a simple process crash, due to the Itanium's unique architecture; however, the system could be indirectly compromised if it shared a security environment with an unprotected VAX or un-patched Alpha system, such as within a mixed VMSCluster. Overall, on a vulnerable system with a default configuration, this vulnerability allowed an attacker with access to the DCL command line to bypass system security and take full control of the system. This is analogous to a privilege escalation attack on a Unix or GNU/Linux system.
The initial point of entry of this exploit is a simple buffer overflow in the DCL command processing code that allows the attacker to gain access to supervisor mode. The subsequent step makes it possible to execute code up to and including kernel mode. This is achieved in part by exploiting the multitasking capability of DCL that allows DCL to interrupt a running program, as well as the fact that DCL retains access to the privileges of the programs that it requests to be loaded into the DCL process. This in turn is partially a result of the process and image activation architecture of OpenVMS, and the fact that in this case it is DCL code in supervisor mode that is responsible for toggling the privileges instead of the OpenVMS kernel. The attacker thus only has to select an image with the CMKRNL privilege to carry out this final step.

Cross-platform applications

OpenVMS supports the following industry standard and open-source tools and applications:
Documentation for Digital Equipment Corporation's OpenVMS Operating System is remembered for their Orange Binders, Large and Small.
DEC's OpenVMS Operating System documentation for various releases, and for various core OpenVMS layered products, is available online at the HPE website.
Software Product Descriptions are introductory and legal descriptions of various products, listing the various supported capabilities and product features.
SPD documents for many OpenVMS-related products, and for OpenVMS itself, are available at Hewlett Packard Enterprise
The OpenVMS Frequently Asked Questions contains information and pointers associated with OpenVMS, and is available in various formats at HoffmanLabs

Releases, software support status

The current OpenVMS release is 8.4-2L1, previous were OpenVMS V8.4-1H1 for Integrity servers, OpenVMS V8.4 for Alpha and OpenVMS V7.3 for VAX servers.
HP provides Current Version Support and Prior Version Support for various OpenVMS releases. The OpenVMS Roadmap guaranteed PVS status for specific releases until 2012, and only then ending with 24 months' prior notice. CVS is provided for the current release and for the immediately prior release.
On July 31, 2014, VMS Software, Inc. announced that HP named VSI as the sole developer of future versions of the OpenVMS operating system and its layered product components. The first release, VSI OpenVMS Version 8.4-1H1, was released June 1, 2015. Next releases will support the latest Itanium hardware. The availability of VSI OpenVMS on x86-based servers for early adopters is planned for 2018.
VSI has assembled a Massachusetts, US-based team of veteran OpenVMS developers, many harkening back to the core DEC team responsible for the initial and ongoing development of OpenVMS.

Applicable industry standards

Some of the industry standards claimed in the OpenVMS Software Product Description are:
Despite being a proprietary commercial operating system, in 1997 OpenVMS and a number of layered products were made available free of charge for hobbyist, non-commercial use as part of the OpenVMS Hobbyist Program. Since then, several companies producing OpenVMS software have made their products available under the same terms, such as Process Software and MVP Systems.
In 2011, HP staff took over the administration of the hobbyist licences. Registration was simplified and remained zero cost. The process from registering to receiving Product Authorisation Keys typically takes about one working day. Software kits for operating system and layered products were made available on request via FTP download. This process is not fully automatic and requires authorisation by HP Hobbyist Program staff.
The Living Computer Museum maintains, among other historic computer systems, a publicly accessible VAX 11/785 running OpenVMS 7.3.
In March 2020, HPE announced that they were concluding the OpenVMS Hobbyist license program. This was followed by an announcement from VSI in April 2020 that VSI they would launch a Community License Program to replace the old Hobbyist Program. The CLP was launched in July 2020, and provides licenses for VSI OpenVMS releases on the Alpha, Itanium and x86-64 platforms. OpenVMS for the VAX is not covered by the CLP, since there are no VSI releases of OpenVMS VAX, and the old versions are still owned by HPE.

Other development efforts

FreeVMS is an attempt to develop an open source operating system following VMS conventions. the associated mailing list had been totally inactive for two years and shown limited activity for some years prior to that. FreeVMS supported the x86-64 architecture using an L4 microkernel.

Influence

VMS is in some ways an ancestor of Windows NT, together with RSX-11 and an unreleased object-based operating system developed by Dave Cutler for DEC Prism. This lineage is made clear in Cutler's foreword to "Inside Windows NT" by Helen Custer.

OpenVMS vocabulary

OpenVMS-related vocabulary include: