Jump to content

OpenVMS

From Alfawiki
OpenVMS
Company typeOperating system
IndustryComputer software
PredecessorVAX/VMS
Founded1977
FounderDigital Equipment Corporation (DEC)
Area served
Worldwide
Key people
Roger Gourd, Dave Cutler, Dick Hustvedt, Peter Lipman
ProductsOpenVMS operating system
ParentVMS Software Inc. (since 2014)

OpenVMS, frequently referred to simply as VMS, is a virtual memory-based operating system designed for multi-user and multiprocessing environments. It supports various modes of operation, including time-sharing, batch processing, transaction handling, and workstation applications.[1] Its clientele encompasses sectors such as banking and financial services, healthcare, telecommunications, network information services, and industrial manufacturing.Cite error: The opening <ref> tag is malformed or has a bad name During the 1990s and early 2000s, approximately half a million VMS installations were active globally.Cite error: The opening <ref> tag is malformed or has a bad name

Initially introduced by Digital Equipment Corporation (DEC) in 1977 as VAX/VMS alongside the VAX-11/780 minicomputer,[2] OpenVMS was subsequently adapted to run on DEC Alpha systems, HPE Integrity Servers based on Itanium architecture,Cite error: The opening <ref> tag is malformed or has a bad name and selected x86-64 platforms including hypervisors.[3] Since 2014, VMS Software Inc. (VSI) has been responsible for its development and support.[4][5] OpenVMS achieves high system availability through clustering technology that distributes workloads across several physical machines, allowing uninterrupted operation during maintenance or hardware issues.[6] Some clusters have demonstrated operational uptimes surpassing 17 years.Cite error: The opening <ref> tag is malformed or has a bad name

Origins and naming evolution

In April 1975, Digital Equipment Corporation (DEC) embarked on creating a 32-bit extension to its PDP-11 series. The hardware project carried the codename Star, while the operating system under development was called Starlet. Roger Gourd managed the VMS initiative, with key technical contributions from software engineers Dave Cutler, Dick Hustvedt, and Peter Lipman.Cite error: The opening <ref> tag is malformed or has a bad name To address the fragmentation caused by numerous incompatible PDP-11 operating systems, the new OS was designed to support real-time processing, time-sharing, and transaction processing capabilities.[7] This initiative culminated in the release of the VAX-11/780 computer alongside the VAX/VMS operating system. The original Starlet codename endures within system libraries such as STARLET.OLB.[8] The majority of VMS was developed using VAX MACRO, supplemented by components written in BLISS.[9]

A primary objective was maintaining backward compatibility with DEC’s RSX-11M operating system.[9] Prior to version 4.0, VAX/VMS included an RSX Application Migration Executive (RSX AME), which allowed unaltered RSX-11M user-mode applications to run.[10] This facilitated early adoption of RSX utilities until native VAX versions were created.[9] By version 3.0, all compatibility tools had been replaced by native implementations.Cite error: The opening <ref> tag is malformed or has a bad name The RSX AME layer was removed with V4.0 and substituted by an optional layered product named VAX-11 RSX.Cite error: The opening <ref> tag is malformed or has a bad name

By the early 1980s, VAX/VMS had achieved commercial success. The database firm Ingres ported its software to VMS due to strong demand, prioritizing it over their Unix version.[11]

Several variants of VAX/VMS were released:

  • MicroVMS catered to smaller systems such as MicroVAX and VAXstation, which had limited memory and storage capacities.Cite error: The opening <ref> tag is malformed or has a bad name It modularized the operating system into kits allowing customized installations.Cite error: The opening <ref> tag is malformed or has a bad name MicroVMS was available for V4.x releases but was discontinued starting with V5.0.Cite error: The opening <ref> tag is malformed or has a bad nameCite error: The opening <ref> tag is malformed or has a bad name
  • Desktop-VMS combined VMS with DECwindows, DECnet networking, and clustering support onto a single CD-ROM targeting VAXstation machines. It was designed for users without extensive technical expertise and could operate directly from CD or be installed on a hard drive.Cite error: The opening <ref> tag is malformed or has a bad nameCite error: The opening <ref> tag is malformed or has a bad nameCite error: The opening <ref> tag is malformed or has a bad name Desktop-VMS employed its own version numbering beginning at V1.0 aligned with the main V5.x releases.Cite error: The opening <ref> tag is malformed or has a bad name
  • An unofficial Soviet adaptation called MOS VP () emerged in the 1980s for SM 1700 clones of the VAX architecture.Cite error: The opening <ref> tag is malformed or has a bad nameCite error: The opening <ref> tag is malformed or has a bad name This variant introduced Cyrillic character support along with Russian language interface translations.Cite error: The opening <ref> tag is malformed or has a bad name Other related derivatives included MicroMOS VP and MOS-32M.

With the introduction of version 5.0 in April 1988, DEC abbreviated the product's name to VMS.Cite error: The opening <ref> tag is malformed or has a bad name Subsequently, in July 1992,[12] DEC rebranded it as OpenVMS to emphasize adherence to open standards such as POSIX and Unix compatibility,[13] signaling its expansion beyond solely the VAX platform. OpenVMS first appeared with the OpenVMS AXP V1.0 release in November 1992; meanwhile, the OpenVMS VAX designation was used starting with version 6.0 in June 1993.Cite error: The opening <ref> tag is malformed or has a bad name

Porting to Alpha

In the 1980s, DEC sought to succeed the VAX platform and VMS operating system with the PRISM architecture and MICA OS. However, after these initiatives were terminated in 1988, a dedicated team concentrated on developing new VAX/VMS systems capable of matching the performance of RISC-based Unix machines. Multiple efforts to produce a faster VAX-compatible processor proved unsuccessful, which led to demonstrating that VMS and its applications could be migrated to a RISC architecture inspired by PRISM. This process ultimately gave rise to the Alpha architecture. The VMS transition to Alpha commenced in 1989, with the first successful boot occurring on a prototype Alpha EV3-based platform in early 1991.

A significant obstacle was that VMS was deeply integrated with VAX hardware, as much of its kernel, layered software, and customer applications were implemented in VAX MACRO assembly language. To disentangle VMS from VAX dependencies, DEC created the MACRO-32 compiler, which treated VAX MACRO code as a high-level language compiling directly into Alpha object code. Additionally, essential VAX hardware features were emulated within PALcode, including interrupt management and atomic operations.

This porting effort resulted in two distinct codebases: one for VAX and another for Alpha, with the Alpha version originating from a snapshot of VAX/VMS around version 5.4-2. In 1992, DEC introduced OpenVMS AXP V1.0 targeting Alpha hardware. By the release of OpenVMS V6.1 in 1994, feature parity between the VAX and Alpha editions was achieved through the Functional Equivalence update. The initial use of version numbers beginning with 1.x for early OpenVMS AXP releases caused some confusion among customers and was not repeated in subsequent platform ports.

At launch, OpenVMS on Alpha supported only 32-bit addressing to preserve compatibility with existing software; 64-bit support was added starting with version 7.0. OpenVMS allows mixed pointer usage within a single codebase, facilitating interoperability between 32-bit and 64-bit executables. The 64-bit OpenVMS Alpha edition supports up to an 8TiB virtual address space (43-bit addressing), consistent with the capabilities of Alpha processors such as the 21064 and 21164.

A distinctive feature exclusive to Alpha was OpenVMS Galaxy, which enabled logical partitioning of one SMP server so multiple OpenVMS instances could run concurrently. Galaxy allowed dynamic resource distribution among partitions and shared memory usage, improving scalability and maximizing resource efficiency on enterprise-grade servers.

Porting to Intel Itanium

In 2001, prior to its acquisition by Hewlett-Packard, Compaq announced plans to port OpenVMS to the Intel Itanium architecture. This decision followed Compaq’s move to phase out the Alpha architecture in favor of Itanium processors. Development on the port began late that year, culminating in a successful boot on January 31, 2003, using an HP i2000 workstation. The Itanium port supports selected HPE Integrity Server models and was initially marketed as HP OpenVMS Industry Standard 64 for Integrity Servers, often shortened to OpenVMS I64 or OpenVMS for Integrity Servers.

The port leveraged shared source code from the OpenVMS Alpha codebase, augmented by conditional compilation and modules tailored specifically for Itanium. Architectural dependencies were either replaced or emulated; this included adopting the Extensible Firmware Interface (EFI) for system booting, reimplementing Alpha PALcode functionality within the kernel, transitioning to new executable formats (Executable and Linkable Format and DWARF), and standardizing on IEEE 754 floating-point representation.

To facilitate migration efforts, the Alpha Environment Software Translator (AEST) allowed user-mode Alpha binaries—and previously translated VAX executables—to execute on Itanium without requiring recompilation.

Two pre-release versions—OpenVMS I64 V8.0 and V8.1—were distributed in mid and late 2003 for HP and third-party partners. The first official production release, version V8.2, arrived in February 2005 supporting both Alpha and Itanium platforms. Subsequent releases within the V8.x series have maintained consistent feature sets across these architectures.

Porting to x86-64

Following VMS Software Inc.'s (VSI) acquisition of OpenVMS development rights from HP, the company announced intentions to adapt OpenVMS for the x86-64 platform. This initiative progressed concurrently with VSI's work on their Itanium and Alpha versions of OpenVMS V8.4-x.

The x86-64 adaptation specifically targets server models from HPE and Dell, as well as certain virtual machine hypervisor environments. Initial compatibility centered on KVM and VirtualBox, with VMware integration introduced in 2020 and Hyper-V support under evaluation. In 2021, the port was successfully demonstrated on a single-board computer powered by an Intel Atom processor.

To facilitate the porting process and ongoing maintenance, VSI transitioned from the proprietary GEM compiler backend to LLVM, altered the boot sequence to initiate OpenVMS loading from a memory disk, and emulated OpenVMS's four privilege levels in software due to the absence of equivalent hardware support on x86-64 processors.

The first successful system boot occurred on May 14, 2019, running OpenVMS within VirtualBox and executing the DIRECTORY command. In May 2020, VSI distributed the V9.0 Early Adopter's Kit to select users, which included OpenVMS running inside a VirtualBox virtual machine with limited layered products and cross-compilation capabilities for x86-64 from Itanium-based hosts. Subsequent updates (from V9.0-A through V9.0-H) enhanced features and broadened hypervisor support.

In June 2021, VSI released the V9.1 Field Test version for customers and collaborators. This iteration was delivered as an ISO image allowing installation across multiple hypervisors and on HPE ProLiant DL380 servers, beginning with the V9.1-A update.

Legacy and Influence

During the 1980s, DEC planned the MICA operating system for its PRISM architecture as a next-generation replacement for VMS, designed to run both VMS and Ultrix applications atop a unified kernel. However, cancellation of both MICA and PRISM led Dave Cutler to depart DEC and join Microsoft. At Microsoft, Cutler spearheaded Windows NT’s development, drawing heavily on MICA’s design principles. As a result, VMS is considered a foundational predecessor of Windows NT, alongside RSX-11, VAXELN, and MICA itself, sharing significant architectural traits.

An abandoned initiative named FreeVMS sought to develop an open-source operating system inspired by VMS conventions. Built upon the L4 microkernel and targeting x86-64 hardware, FreeVMS exemplified continued interest in microkernel-based VMS designs. Earlier prototyping efforts by DEC and Carnegie Mellon University utilized the Mach 3.0 microkernel on VAXstation 3100 systems, employing a multiserver architecture.

Architecture

OpenVMS employs a layered architectural model consisting of a highly privileged Executive, an intermediate Command Language Interpreter with moderate privileges, and unprivileged utilities along with run-time libraries (RTLs). Unprivileged components access Executive functions through system services, analogous to traditional system call mechanisms.

The operating system exploits several distinctive features of the VAX architecture:

  • Four distinct processor access modes—Kernel, Executive, Supervisor, and User—each maintaining separate stacks and individual memory protection schemes.
  • A virtual address space partitioned into private segments for each process alongside shared system areas.
  • Thirty-two interrupt priority levels utilized for synchronization purposes.
  • Hardware provisions supporting asynchronous system traps.

On Alpha, Itanium, and x86-64 platforms, these features are either mapped onto corresponding hardware capabilities or emulated through PALcode or software layers.

Executive and Kernel

The Executive encompasses privileged code and data within the system space, divided into the Kernel (operating in kernel mode) and the executive mode components, which possess a lower privilege level.

Within executive mode reside elements such as Record Management Services and specific system services like image activation. Although most essential OS data structures can be read while in executive mode, modifications require kernel mode access. The executive code has the capability to transition into kernel mode at will, making this division more of a precaution against inadvertent corruption than a rigid security measure.

The Kernel is responsible for managing fundamental data structures—including page tables, the I/O database, and scheduling—and is composed of three primary subsystems: I/O, Process and Time Management, and Memory Management. Additionally, it oversees logical name management, synchronization mechanisms, and the dispatching of system services.

Code executing in user mode that holds sufficient privileges can switch to executive or kernel modes using the $CMEXEC and $CMKRNL system services. This functionality facilitates third-party extensions and permits core utilities to interact with OS data structures through privileged interfaces.

File system

Access to the file system in OpenVMS is primarily provided through Record Management Services (RMS), although applications may also interact directly via QIO system services. The supported file systems are referred to as Files-11 On-Disk Structures (ODS), with ODS-2 and ODS-5 being the most widely used variants. OpenVMS further supports file access on ISO 9660 CD-ROMs and magnetic tapes formatted with ANSI tape labels.

Files-11 volumes have a maximum size limit of 2 TiB. In 1995, DEC introduced the log-structured Spiralog file system as a potential replacement; however, due to challenges such as managing full volumes, Spiralog was eventually discontinued. Current development conversations include efforts to port the open-source GFS2 file system to OpenVMS.

Command Language Interpreter

The OpenVMS Command Language Interpreter (CLI) offers a command-line interface for running commands and command procedures, which are akin to shell scripts. The default CLI implementation is the DIGITAL Command Language, though alternative options exist.

Unlike Unix shells that execute as independent processes, OpenVMS CLIs function as optional components embedded within a process alongside any executable image. Instead of creating new processes through fork-exec semantics, the CLI loads executable images into the same process, transfers control to them, then regains control upon their completion while restoring the original process state.

To safeguard its code and data from modification by user-mode programs, the CLI operates at supervisor access mode within the process address space, granting it privileges higher than standard user-level code.

Clustering

OpenVMS offers support for clustering—initially called VAXcluster and later renamed VMScluster—which allows multiple computers to run independent instances of the operating system. Cluster nodes can share resources such as disk drives and printers, coordinating through communication mechanisms to present a unified single system image to users. Nodes connect via proprietary Cluster Interconnect hardware or standard Ethernet LAN technology.

Clusters can scale up to 96 nodes and accommodate mixed hardware architectures. This clustering capability ensures continuous application availability during both planned maintenance and unexpected failures, including hardware replacements and software updates.

Networking

The VMS operating system incorporates the DECnet protocol suite, facilitating remote user logins and seamless sharing of files, printers, and other networked resources. Early iterations, such as VAX/VMS Version 1.0, supported DECnet Phase II, while contemporary releases accommodate both Phase IV and the OSI-compliant Phase V, also known as DECnet-Plus. For TCP/IP connectivity, an optional package called TCP/IP Services for OpenVMS (previously VMS/ULTRIX Connection) is available, which is derived from a BSD networking stack port. This suite supports a variety of protocols including SSH, DHCP, FTP, and SMTP.

DEC's PATHWORKS software (initially named PCSA) allowed personal computers running MS-DOS, Windows, OS/2, or Macintosh to function as terminals or file and print servers connected to VMS environments. Over time, PATHWORKS transitioned into Advanced Server for OpenVMS, which was eventually superseded by a port of Samba tailored for VMS during the shift to Itanium processors.

The company also created the Local Area Transport (LAT) protocol to link remote terminals and printers through terminal servers such as those in the DECserver product line.

Programming

DEC and its successors have provided extensive programming language support for VMS systems. The officially supported languages, both historical and current, encompass:


A distinctive aspect of OpenVMS is its Common Language Environment, a rigorous standard that specifies calling conventions—including stack and register usage—across different programming languages. This framework allows routines written in one language to invoke those in another seamlessly (for example, Fortran calling COBOL) without revealing internal implementation details. The operating system itself is constructed using multiple languages that interoperate through this environment. Additionally, DEC introduced the Structure Definition Language (SDL), which enables unified data type definitions to be generated across various languages from a single source.

The system natively supports languages such as C, Fortran, Pascal, BASIC, C++, BLISS, and COBOL. Furthermore, open-source languages including Lua, PHP, Python, Scala, and Java are readily accessible for use on the platform.

Development Tools

DEC provided a collection of software development utilities under the name DECset (initially known as VAXset), which comprised the following components:

The OpenVMS Debugger is compatible with all DEC compilers as well as numerous third-party languages, offering features such as breakpoints, watchpoints, and interactive debugging accessible through both command-line and graphical interfaces. For lower-level debugging of privileged code, the debuggers DELTA and XDELTA are available.

In 2019, VSI introduced an officially supported Integrated Development Environment tailored for VMS, built on top of Visual Studio Code. This IDE facilitates remote development and debugging from Windows, macOS, or Linux platforms.

Database Management

Under the VAX Information Architecture label, DEC developed multiple optional database solutions for VMS, including:

  • Rdb – A relational database initially utilizing the proprietary Relational Data Operator (RDO), later extended to support SQL.
  • DBMS – A database management system based on the CODASYL network model, featuring its own Data Manipulation Language.
  • Digital Standard MUMPS (DSM) – An integrated programming language combined with a key-value database.
  • Common Data Dictionary (CDD) – A centralized schema repository that allows data definitions to be shared across different programming languages.
  • DATATRIEVE – A query and reporting utility capable of accessing RMS files along with Rdb and DBMS databases.
  • Application Control Management System (ACMS) – A transaction processing monitor using a high-level Task Description Language (TDL); supports user interfaces via TDMS, DECforms, or Digital's ALL-IN-1 office suite.
  • RALLY and DECadmire – Fourth-generation programming languages (4GLs) designed for database application development; DECadmire was integrated with ACMS and later supported Visual Basic client-server applications.

In 1994, DEC transferred ownership of Rdb, DBMS, and CDD to Oracle Corporation, where these products continue to be actively developed. The following year, DSM was sold to InterSystems, rebranded as Open M, and subsequently replaced by their Caché product.

Additional third-party database options compatible with OpenVMS include MariaDB, Mimer SQL (available on both Itanium and x86-64 architectures), and System 1032.

User Interfaces

Originally, VMS was created for interactive control through DEC's text-based video terminals such as the VT100 and hardcopy terminals including the DECwriter series. Following the 1984 introduction of the VAXstation family, VMS expanded its capabilities to support graphical user interfaces on workstations and X terminal devices like the VT1000 series.

Text-Based User Interfaces

Since its inception, the primary command language interpreter (CLI) for OpenVMS has been the DIGITAL Command Language (DCL). Additional official CLIs encompass the RSX-11 Monitor Console Routine (MCR) designed for VAX systems and various Unix shell environments. DEC provided developers with utilities to create text-based UI applications, initially through the Form Management System (FMS) and Terminal Data Management System (TDMS), which were subsequently superseded by DECforms. There is also a lower-level interface named Screen Management Services (SMG$), analogous to the Unix curses library.

Graphical User Interfaces

VMS has undergone several phases of GUI toolkit development and interface enhancements:

  • The first graphical interface, VMS Workstation Software (VWS), debuted in 1984 for the VAXstation I, providing access to the User Interface Services (UIS) API and operating on selected VAX hardware platforms.
  • In 1989, DEC launched DECwindows, an X11-based system included with VAX/VMS V5.1, initially utilizing a proprietary toolkit called X User Interface (XUI). A compatibility layer named UISX allowed applications built with VWS/UIS to function under DECwindows. Elements of XUI later contributed to the development of the Motif toolkit by the Open Software Foundation.
  • By 1991, Motif replaced XUI as the primary toolkit, leading to the creation of DECwindows Motif, which became the standard interface in OpenVMS V6.0 while keeping XUI available as an alternative.
  • The 1996 release of OpenVMS V7.1 introduced the New Desktop interface for DECwindows Motif, based on the Common Desktop Environment (CDE). On Alpha and Itanium platforms, users retained the option to choose the older MWM-based UI known as "DECwindows Desktop" at login. The New Desktop was never ported to VAX versions.

Throughout the 1990s, VMS running on DEC Alpha workstations supported graphics technologies such as OpenGL and Accelerated Graphics Port (AGP) adapters alongside traditional standards like GKS and PHIGS. Contemporary DECwindows implementations are built upon the X.Org Server.

Security

OpenVMS provides extensive security mechanisms, including security identifiers, resource identifiers, subsystem identifiers, ACLs, intrusion detection systems, and thorough security auditing with alarm capabilities. Certain editions have undergone evaluation against the Trusted Computer System Evaluation Criteria at Class C2 and, with the SEVMS enhanced version, at Class B1. Additionally, OpenVMS holds an ITSEC E3 certification. Password protection employs hashing based on the Purdy Polynomial.

Security Weaknesses

  • Initial releases of VMS contained privileged accounts such as SYSTEM and FIELD with preset passwords that administrators frequently neglected to modify. This oversight was exploited by multiple computer worms, including the WANK worm and Father Christmas worm, to gain unauthorized entry into DECnet nodes. The vulnerability was prominently highlighted by Clifford Stoll in his book The Cuckoo's Egg. Starting with version V5.0, default passwords were eliminated, and the system required the creation of passwords for these accounts during installation.
  • In 2017, a vulnerability dating back 33 years (CVE-2017-17482) was uncovered affecting VMS on both VAX and Alpha systems. This flaw permitted users with access to the DCL command line to escalate privileges through a buffer overflow in the DCL command interpreter. The attack method involved interrupting an active program to return to the DCL prompt while preserving the privileges of the interrupted process, enabling execution of elevated shellcode. When combined with privileged system images, this weakness could circumvent security controls.

POSIX Compliance

Multiple official compatibility layers for Unix and POSIX standards have been developed for VMS. The earliest, DEC/Shell, ported the Bourne shell from Version 7 Unix along with various Unix utilities to VAX/VMS platforms. In 1992, DEC introduced POSIX for OpenVMS, which featured a shell derived from the KornShell. This was later superseded by the open-source GNV (GNU's not VMS) project, distributed with OpenVMS starting in 2002, providing GNU utilities including a port of the Bash shell tailored for VMS. Additionally, third-party Unix compatibility solutions such as Eunice are available.

Hobbyist Software

In 1997, OpenVMS along with several associated layered products became accessible at no cost for non-commercial hobbyist use through the OpenVMS Hobbyist Program. Following this, certain OpenVMS software vendors like Process Software adopted similar licensing terms for their offerings. Prior to the x86-64 port availability, hobbyists often relied on emulators such as SIMH due to the expense and aging condition of hardware capable of running OpenVMS.

The OpenVMS Hobbyist Program was discontinued by HPE in March 2020. In response, VSI established the Community License Program (CLP) in July 2020 as its successor, granting licenses for VSI OpenVMS across Alpha, Integrity, and x86-64 platforms. The CLP does not cover OpenVMS on VAX systems because VSI has no releases for that architecture and older versions remain under HPE control.

Version History

Template:Version January 1985 Added MicroVAX/VAXstation I and II support ... [Entries abbreviated here while preserving key milestones] ... Template:Version June 2001 - December 2012 Final update supporting VAX architecture Template:Version June 2004 Enhanced Alpha platform features including ATM and Gigabit Ethernet clustering; Extended File Cache introduced Template:Version June 2003 - December 2003 IA64 evaluation release targeting Integrity servers Template:Version December 2003 - February 2005 Second IA64 evaluation release for Integrity server platforms Template:Version February 2005 - June 2010 Production release supporting both Alpha and IA64 architectures Template:Version June 2010 - December 2020 Support extended to HPVM and TCP/IP clusters on Alpha and IA64 systems Template:Version May 2015 - December 2022 IA64 enhancements including Poulson processors and HPE BL890c systems with updated UEFI firmware Template:Version July 2017 Final Alpha architecture release; extended maintenance through December 2035 Template:Version April 2021 Last Integrity server (IA64) release version Template:Version May 2020 - June 2021 Early Adopter's Kit launched by VSI targeting x86-64 hardware platforms Template:Version June 2021 - September 2021 Field Test release on x86-64 featuring enhanced capabilities and subsequent DECnet-Plus integration Template:Version July 2022 - June 2023 Limited Production Release on x86-64 supporting AMD CPUs, OpenSSL version 3.0; native compilers introduced in update V9.2-1 (June 2023) extending support through June 2025 Template:Version January 2024 - December 2027 Maintenance updates focused on bug fixes ensuring platform stability on x86-64 architecture Template:Version November 2024 - December 2028 Introduces VMware vMotion and VMDirectPath virtualization enhancements improving cloud integration capabilities Template:Version June 2026 - TBA Planned introduction of iSCSI support aimed at expanding storage networking options
Chronology of OpenVMS Releases
Version Vendor Release Date Support End Date Platform Noteworthy Updates and Hardware Support
Template:Version DEC April 1978 rowspan=54 Template:Dunno VAX Initial customer shipment
Template:Version August 1978 First official production version
Template:Version Template:Dunno Stability improvements
Template:Version February 1979 Added native COBOL and BLISS compiler support
Template:Version August 1979 Updates to RMS-11 file system
Template:Version April 1980 Introduced support for VAX-11/750 and new utilities including EDT editor
Template:Version Template:Dunno Template:Dunno
Template:Version April 1981 Raised process limit to 8,192 concurrent processes
Template:Version May 1981 Security improvements implemented
Template:Version Template:Dunno Template:Dunno
Template:Version Template:Dunno Introduced BACKUP utility
Template:Version April 1982 Added support for VAX-11/730, VAX-11/725, VAX-11/782; included ASMP support
Template:Version August 1982 PL/I runtime environment integrated into base OS package
Template:Version December 1982 Support added for RA60, RA80, RA81 disk drives
Template:Version April 1983 Included HSC50 disk controller support; BACKUP utility enhancements
Template:Version June 1983 Enabled Ethernet support for DECnet; added VAX-11/785 compatibility
Template:Version November 1983 Added support for additional I/O devices
Template:Version April 1984 Bug fixes released
Template:Version August 1984 Extended support for new I/O hardware
Template:Version September 1984 Released support for VAX 8600; introduced MicroVMS and VAXclusters


See also

Further reading

  • Getting Started with OpenVMS, Michael D. Duffy
  • Introduction to OpenVMS, 5th Edition, Lesley Ogilvie Rice
  • OpenVMS Alpha Internals and Data Structures: Memory Management, Ruth Goldenberg
  • OpenVMS Alpha Internals and Data Structures: Scheduling and Process Control: Version 7.0, Ruth Goldenberg, Saro Saravanan, Denise Dumas
  • VAX/VMS Internals and Data Structures: Version 5.2 ("IDSM"), Ruth Goldenberg, Saro Saravanan, Denise Dumas
  • Writing Real Programs in DCL, 2nd edition, Stephen Hoffman, Paul Anagnostopoulos
  • Writing OpenVMS Alpha Device Drivers in C, Margie Sherlock, Leonard Szubowicz
  • OpenVMS Performance Management, Joginder Sethi
  • Getting Started with OpenVMS System Management, 2nd Edition, David Donald Miller, Stephen Hoffman, Lawrence Baldwin
  • The OpenVMS User's Guide, 2nd Edition, Patrick Holmay
  • Using DECwindows Motif for OpenVMS, Margie Sherlock
  • The hitchhiker's guide to VMS: an unsupported-undocumented-can-go-away-at-any-time feature of VMS, Bruce Ellis

External links

  1. ↑ Cite error: Invalid <ref> tag; no text was provided for refs named vms-8.4-spd
  2. ↑ Cite error: Invalid <ref> tag; no text was provided for refs named RIP.CW1977
  3. ↑ Cite error: Invalid <ref> tag; no text was provided for refs named 9.0 Rollout
  4. ↑ Cite error: Invalid <ref> tag; no text was provided for refs named vms-software-named-exclusive-developer
  5. ↑ Cite error: Invalid <ref> tag; no text was provided for refs named NotPressRelease
  6. ↑ Cite error: Invalid <ref> tag; no text was provided for refs named cluster-docs
  7. ↑ Cite error: Invalid <ref> tag; no text was provided for refs named bellstreckerpdp11vaxalpha
  8. ↑ Cite error: Invalid <ref> tag; no text was provided for refs named what-is-vms
  9. ↑ 9.0 9.1 9.2 Cite error: Invalid <ref> tag; no text was provided for refs named vms-20-years
  10. ↑ Cite error: Invalid <ref> tag; no text was provided for refs named vms-1.0-spd
  11. ↑ Cite error: Invalid <ref> tag; no text was provided for refs named rdbmsingressybase20070613
  12. ↑ Cite error: Invalid <ref> tag; no text was provided for refs named DuffB
  13. ↑ Cite error: Invalid <ref> tag; no text was provided for refs named POSix
Retrieved from "https://www.alfawiki.org/index.php?title=OpenVMS&oldid=21834"