Editing OpenVMS (section)

==Architecture==

[[File:Openvms-system-architecture.svg|thumb|275px|The architecture of the OpenVMS operating system, demonstrating the layers of the system, and the access modes in which they typically run]]

The OpenVMS operating system has a layered architecture, consisting of a privileged ''Executive'', an intermediately privileged Command Language Interpreter, and unprivileged utilities and [[Runtime library|run-time libraries]] (RTLs).<ref name="idsm-5.2">{{cite book|title=VAX/VMS Internals and Data Structures, Version 5.2|url=https://books.google.com/books?id=D7xQAAAAMAAJ|isbn=978-1555580599|author1=Ruth E. Goldenberg|author2=Lawrence J. Kenah|author3=Denise E. Dumas|publisher=Digital Press|date=1991}}</ref> Unprivileged code typically invokes the functionality of the Executive through ''system services'' (equivalent to [[system call]]s in other operating systems).

OpenVMS' layers and mechanisms are built around certain features of the VAX architecture, including:<ref name="idsm-5.2" /><ref name="goatley-part-1">{{cite web|url=https://hunter.goatley.com/vms/internals1.html|title=Writing VMS Privileged Code Part I: The Fundamentals, Part 1|author1=Hunter Goatley|author2=Edward A. Heinrich|website=hunter.goatley.com|access-date=January 31, 2021}}</ref>

* The availability of four [[protection ring|processor access modes]] (named ''Kernel'', ''Executive'', ''Supervisor'' and ''User'', in order of decreasing privilege). Each mode has its own stack, and each [[memory page]] can have [[memory protection]]s specified per-mode.
* A [[virtual address space]] which is partitioned between process-private space sections, and system space sections which are common to all processes.
* 32 [[interrupt priority level]]s which are used for [[Synchronization (computer science)|synchronization]].
* Hardware support for delivering [[asynchronous system trap]]s to processes.

These VAX architecture mechanisms are implemented on Alpha, Itanium and x86-64 by either mapping to corresponding hardware mechanisms on those architectures, or through emulation (via [[PALcode]] on Alpha, or in software on Itanium and x86-64).<ref name="swis" />

===Executive and Kernel===

The OpenVMS Executive comprises the privileged code and data structures which reside in the system space. The Executive is further subdivided between the ''Kernel'', which consists of the code which runs at the kernel access mode, and the less-privileged code outside of the Kernel which runs at the executive access mode.<ref name="idsm-5.2" />

The components of the Executive which run at executive access mode include the [[Record Management Services]], and certain system services such as image activation. The main distinction between the kernel and executive access modes is that most of the operating system's core data structures can be read from executive mode, but require kernel mode to be written to.<ref name="goatley-part-1" /> Code running at executive mode can switch to kernel mode at will, meaning that the barrier between the kernel and executive modes is intended as a safeguard against accidental corruption as opposed to a security mechanism.<ref>{{cite conference|url=https://www.scs.stanford.edu/nyu/04fa/sched/readings/vmm.pdf|title=A VMM security kernel for the VAX architecture|author1=Paul A. Karger|author2=Mary Ellen Zurko|author3=Douglas W. Benin|author4=Andrew H. Mason|author5=Clifford E. Kahnh|date=May 7–9, 1990|conference=Proceedings. 1990 IEEE Computer Society Symposium on Research in Security and Privacy|access-date=January 31, 2021|publisher=IEEE|doi=10.1109/RISP.1990.63834}}</ref>

The [[Kernel (operating system)|Kernel]] comprises the operating system's core data structures (e.g. page tables, the I/O database and scheduling data), and the routines which operate on these structures. The Kernel is typically described as having three major subsystems: I/O, Process and Time Management, Memory Management.<ref name="idsm-5.2" /><ref name="goatley-part-1" /> In addition, other functionality such as [[Files-11#Logical names|logical name]] management, synchronization and system service dispatch are implemented inside the Kernel.

OpenVMS allows user-mode code with suitable privileges to switch to executive or kernel mode using the <code>$CMEXEC</code> and <code>$CMKRNL</code> system services, respectively.<ref>{{cite web|url=https://vmssoftware.com/docs/VSI_SYS_SERVICES_REF_VOL_I.PDF|title=VSI OpenVMS System Services Reference Manual: A–GETUAI|publisher=VSI|date=June 2020|access-date=February 15, 2021}}</ref> This allows code outside of system space to have direct access to the Executive's routines and system services. In addition to allowing third-party extensions to the operating system, Privileged Images are used by core operating system utilities to manipulate operating system data structures through undocumented interfaces.<ref name="inside-vms">{{cite book|title=Inside VMS: The System Manager's and System Programmer's Guide to VMS Internals|url=https://books.google.com/books?id=c4UhAQAAIAAJ|isbn=0-442-00474-5|author=Wayne Sewell|year=1992|publisher=Van Nostrand Reinhold}}</ref>

===File system===
{{Main|Files-11|Record Management Services}}
The typical user and application interface into the [[file system]] is the [[Record Management Services]] (RMS), although applications can interface directly with the underlying file system through the [[QIO]] system services.<ref name="acp-qio-doc">{{cite web|url=https://vmssoftware.com/docs/VSI_IO_REF.pdf|title=VSI OpenVMS I/O User's Reference Manual|date=August 2019|access-date=January 13, 2021|publisher=VSI}}</ref> The file systems supported by VMS are referred to as the [[Files-11]] ''On-Disk Structures'' (ODS), the most significant of which are ''ODS-2'' and ''ODS-5''.<ref name="andy-goldstein-files-11">{{cite web|url=https://www.youtube.com/watch?v=b0YenelPw-Y| archive-url=https://web.archive.org/web/20210112225121/https://www.youtube.com/watch?v=b0YenelPw-Y| archive-date=January 12, 2021 | url-status=dead|title=Andy Goldstein on Files-11, the OpenVMS File Systems|date=July 25, 2019|access-date=January 3, 2021|publisher=VSI Official Channel}}</ref> VMS is also capable of accessing files on [[ISO 9660]] [[CD-ROM]]s and [[magnetic tape]] with [[Tape labels#ANSI tape labels|ANSI tape labels]].<ref>{{cite web|url=https://vmssoftware.com/docs/VSI_Gd_to_File_Apps_23Jul19.pdf|title=VSI OpenVMS Guide to OpenVMS File Applications|publisher=VSI|date=July 23, 2019|access-date=January 13, 2021}}</ref>

Files-11 is limited to 2 TiB volumes.<ref name="andy-goldstein-files-11" /> DEC attempted to replace it with a [[log-structured file system]] named Spiralog, first released in 1995.<ref name="Why was Spiralog retired">{{cite web|url=https://community.hpe.com/t5/Operating-System-OpenVMS/Why-was-Spiralog-retired/td-p/4951205|title=Why was Spiralog retired?|date=January 10, 2006|access-date=January 13, 2021|website=Hewlett Packard Enterprise Community - Operating System - OpenVMS}}</ref> However, Spiralog was discontinued due to a variety of problems, including issues with handling full volumes.<ref name="Why was Spiralog retired"/> Instead, there has been discussion of porting the open-source GFS2 file system to OpenVMS.<ref name="september-2020-roadmap">{{cite web|url=https://vmssoftware.com/pdfs/VMS_Software_Roadmap_2020.pdf|archive-url=https://web.archive.org/web/20201207040724/https://vmssoftware.com/pdfs/VMS_Software_Roadmap_2020.pdf|archive-date=December 7, 2020|url-status=dead|title=VSI OpenVMS Software Roadmap 2020|access-date=September 23, 2020|date=September 2020}}</ref>

===Command Language Interpreter===

An OpenVMS Command Language Interpreter (CLI) implements a [[command-line interface]] for OpenVMS, responsible for executing individual commands and ''command procedures'' (equivalent to [[shell script]]s or [[batch file]]s).<ref name="user-guide">{{cite web|url=https://vmssoftware.com/docs/VSI_USERS_MANUAL.pdf|title=OpenVMS User's Manual|at=Chapter 14, Advanced Programming with DCL|website=VSI|access-date=April 9, 2021|date=July 2020}}</ref> The standard CLI for OpenVMS is the [[DIGITAL Command Language]], although other options are available.

Unlike [[Unix shell]]s, which typically run in their own isolated process and behave like any other user-mode program, OpenVMS CLIs are an optional component of a process, which exist alongside any executable image which that process may run.<ref name="dcl-supervisor-thread">{{cite newsgroup|url=https://comp.os.vms.narkive.com/Wc1uHZU3/how-dangerous-is-it-to-be-able-to-get-into-dcl-supervisor-mode|title=How dangerous is it to be able to get into DCL supervisor mode?|author=Simon Clubley|date=July 3, 2017|newsgroup=comp.os.vms|access-date=February 1, 2021}}</ref> Whereas a Unix shell will typically run executables by creating a separate process using [[fork-exec]], an OpenVMS CLI will typically load the executable image into the same process, transfer control to the image, and ensure that control is transferred back to CLI once the image has exited and that the process is returned to its original state.<ref name="idsm-5.2" />

Because the CLI is loaded into the same address space as user code, and the CLI is responsible for invoking image activation and image rundown, the CLI is mapped into the process address space at supervisor access mode, a higher level of privilege than most user code. This is in order to prevent accidental or malicious manipulation of the CLI's code and data structures by user-mode code.<ref name="idsm-5.2"/><ref name="dcl-supervisor-thread" />