OpenVMS

OpenVMS, a menudo denominado simplemente VMS, es un sistema operativo multiusuario, multiprocesador y basado en memoria virtual. Está diseñado para admitir aplicaciones de tiempo compartido, procesamiento por lotes, procesamiento de transacciones y estaciones de trabajo. Los clientes que utilizan OpenVMS incluyen bancos y servicios financieros, hospitales y atención médica, operadores de telecomunicaciones, servicios de información de red y fabricantes industriales. Durante las décadas de 1990 y 2000, había aproximadamente medio millón de sistemas VMS en funcionamiento en todo el mundo.

Fue anunciado por primera vez por Digital Equipment Corporation (DEC) como VAX/VMS (Extensión de dirección virtual/Sistema de memoria virtual) junto con la minicomputadora VAX-11/780 en 1977. Posteriormente, OpenVMS se ha portado para ejecutarse en sistemas DEC Alpha, los servidores HPE Integrity basados en Itanium y hardware e hipervisores x86-64 seleccionados. Desde 2014, OpenVMS es desarrollado y respaldado por VMS Software Inc. (VSI). OpenVMS ofrece alta disponibilidad a través de la agrupación en clúster: la capacidad de distribuir el sistema en varias máquinas físicas. Esto permite que las aplicaciones y los datos en clúster permanezcan disponibles continuamente mientras se realiza el mantenimiento y las actualizaciones del software y el hardware del sistema operativo, o si se destruye parte del clúster. Se han informado tiempos de actividad del clúster VMS de 17 años.

Historia

Cambios de origen y nombre

Estilizado "VAX/VMS" utilizado por Digital

En abril de 1975, Digital Equipment Corporation se embarcó en un proyecto para diseñar una extensión de 32 bits para su línea de computadoras PDP-11. El componente de hardware tenía el nombre en código Estrella; el sistema operativo tenía el nombre en código Starlet. Roger Gourd fue el líder del proyecto de VMS. Los ingenieros de software Dave Cutler, Dick Hustvedt y Peter Lipman actuaron como líderes técnicos del proyecto. Los proyectos Star y Starlet culminaron en la computadora VAX-11/780 y el sistema operativo VAX/VMS. El nombre en clave del proyecto Starlet sobrevive en VMS en el nombre de varias de las bibliotecas del sistema, incluidas STARLET.OLB y STARLET.MLB. VMS se escribió principalmente en VAX MACRO con algunos componentes escritos en BLISS.

Uno de los objetivos originales de VMS era la compatibilidad con versiones anteriores del sistema operativo RSX-11M existente de DEC. Antes del lanzamiento de V3.0, VAX/VMS incluía una capa de compatibilidad denominada Ejecutivo de migración de aplicaciones RSX (RSX AME) que permitía ejecutar el software RSX-11M en modo de usuario sin modificaciones sobre VMS. El RSX AME desempeñó un papel importante en las primeras versiones de VAX/VMS, que utilizaban ciertas utilidades de modo de usuario RSX-11M reutilizadas antes de que se desarrollaran las versiones nativas de VAX. En la versión V3.0, todas las utilidades del modo de compatibilidad se reemplazaron con implementaciones nativas. En VAX/VMS V4.0, RSX AME se eliminó del sistema base y se reemplazó con un producto en capas opcional denominado VAX-11 RSX.

"Albert the Cheshire Cat" mascota para VAX/VMS, utilizado por el DECUS VAX SIG

Se crearon varias distribuciones de VAX/VMS:

• MicroVMS fue una distribución de VAX/VMS diseñada para MicroVAX y VAXstation hardware, que tenía menos memoria y espacio en disco que sistemas VAX más grandes de la época. MicroVMS dividió VAX/VMS en múltiples kits, que un cliente podría utilizar para instalar un subconjunto de VAX/VMS adaptado a sus necesidades específicas. Se produjeron lanzamientos de microVMS para cada una de las versiones V4.x de VAX/VMS y se suspendió cuando VAX/VMS V5.0 fue liberado.
• Desktop-VMS fue una distribución corta de VAX/VMS vendida con sistemas VAXstation. Consistió en un único CD-ROM que contenía un paquete de VMS, DECwindows, DECnet, soporte VAXcluster y un proceso de configuración diseñado para usuarios no técnicos. Desktop-VMS puede funcionar directamente desde el CD, o puede instalarse en un disco duro. Desktop-VMS tenía su propio esquema de versión comenzando con V1.0, que correspondía a las versiones V5.x de VMS.
• Un derivado no oficial de VAX/VMS llamado MOS VP (Ruso: Многофункциональная операционая система с виртуальной памятью, МОС ВПППП, iluminado.'Multifunctional Operating System with Virtual Memory') fue creado en la Unión Soviética durante la década de 1980 para la línea SM 1700 del hardware clon VAX. MOS VP agregó soporte para el script Cirílico, y tradujo partes de la interfaz de usuario en ruso. Derivados similares de MicroVMS conocidos como MicroMOS VP (Ruso: МикроМОС П) o MOS-32M (Ruso: МОС-32М) también fueron creados.

Con el lanzamiento de V5.0 en abril de 1988, DEC comenzó a referirse a VAX/VMS simplemente como VMS en su documentación. En julio de 1992, DEC cambió el nombre de VAX/VMS a OpenVMS como una indicación de su compatibilidad con los estándares de la industria de sistemas abiertos, como la compatibilidad con POSIX y Unix, y para abandonar la conexión VAX ya que se estaba realizando una migración a una arquitectura diferente. El nombre OpenVMS se usó por primera vez con la versión OpenVMS AXP V1.0 en noviembre de 1992. DEC comenzó a usar el nombre OpenVMS VAX con la versión V6.0 en junio de 1993.

Puerto a alfa

"Vernon the Shark" logo para OpenVMS

Durante la década de 1980, DEC planeó reemplazar la plataforma VAX y el sistema operativo VMS con la arquitectura PRISM y el sistema operativo MICA. Cuando estos proyectos se cancelaron en 1988, se creó un equipo para diseñar nuevos sistemas VAX/VMS de rendimiento comparable a los sistemas Unix basados en RISC. Después de varios intentos fallidos de diseñar un procesador compatible con VAX más rápido, el grupo demostró la viabilidad de trasladar VMS y sus aplicaciones a una arquitectura RISC basada en PRISM. Esto condujo a la creación de la arquitectura Alpha. El proyecto para portar VMS a Alpha comenzó en 1989 y se inició por primera vez en un prototipo de Unidad de demostración Alpha basada en Alpha EV3 a principios de 1991.

El principal desafío en la migración de VMS a una nueva arquitectura fue que VMS y VAX se diseñaron juntos, lo que significa que VMS dependía de ciertos detalles de la arquitectura VAX. Además, una cantidad significativa del núcleo VMS, los productos en capas y las aplicaciones desarrolladas por el cliente se implementaron en el código ensamblador VAX MACRO. Algunos de los cambios necesarios para desacoplar VMS de la arquitectura VAX incluyeron la creación del compilador MACRO-32, que trató a VAX MACRO como un lenguaje de alto nivel y lo compiló en código objeto Alpha, y el emulación de ciertos detalles de bajo nivel de la arquitectura VAX en PALcode, como el manejo de interrupciones y las instrucciones de cola atómica.

La adaptación de VMS a Alpha resultó en la creación de dos bases de código separadas: una para VAX y otra para Alpha. La biblioteca de código Alpha se basó en una instantánea de la base de código VAX/VMS alrededor de V5.4-2. 1992 vio el lanzamiento de la primera versión de OpenVMS para sistemas Alpha AXP, denominada OpenVMS AXP V1.0. En 1994, con el lanzamiento de OpenVMS V6.1, se logró la paridad de características (y número de versión) entre las variantes VAX y Alpha, esta fue la llamada versión de equivalencia funcional. La decisión de usar el flujo de numeración de la versión 1.x para los lanzamientos de calidad de preproducción de OpenVMS AXP causó confusión entre algunos clientes y no se repitió en los puertos posteriores de OpenVMS a nuevas plataformas.

Cuando VMS se transfirió a Alpha, inicialmente se dejó como un sistema operativo de solo 32 bits. Esto se hizo para garantizar la compatibilidad con versiones anteriores del software escrito para el VAX de 32 bits. El direccionamiento de 64 bits se agregó por primera vez para Alpha en la versión V7.0. Para permitir que el código de 64 bits interopere con el código anterior de 32 bits, OpenVMS no crea una distinción entre los ejecutables de 32 y 64 bits, sino que permite que se utilicen punteros de 32 y 64 bits dentro de el mismo código. Esto se conoce como soporte de puntero mixto. Las versiones Alpha de OpenVMS de 64 bits admiten un tamaño máximo de espacio de direcciones virtuales de 8 TiB (un espacio de direcciones de 43 bits), que es el máximo admitido por Alpha 21064 y Alpha 21164.

Una de las características exclusivas de Alpha más notables de OpenVMS fue OpenVMS Galaxy, que permitió la partición de un único servidor SMP para ejecutar varias instancias de OpenVMS. Galaxy admitió la asignación dinámica de recursos para ejecutar particiones y la capacidad de compartir memoria entre particiones.

Puerto a Intel Itanium

Logo "Swoosh" utilizado por HP para OpenVMS

En 2001, antes de que Hewlett-Packard la adquiriera, Compaq anunció la migración de OpenVMS a la arquitectura Intel Itanium. El puerto Itanium fue el resultado de la decisión de Compaq de interrumpir el desarrollo futuro de la arquitectura Alpha a favor de adoptar la entonces nueva arquitectura Itanium. La migración comenzó a fines de 2001 y el primer inicio tuvo lugar el 31 de enero de 2003. El primer inicio consistió en iniciar una configuración mínima del sistema en una estación de trabajo HP i2000, iniciando sesión como usuario SYSTEM, y ejecutando el comando DIRECTORIO. El puerto Itanium de OpenVMS admite modelos y configuraciones específicos de servidores HPE Integrity. Las versiones de Itanium se denominaron originalmente HP OpenVMS Industry Standard 64 for Integrity Servers, aunque los nombres OpenVMS I64 o OpenVMS for Integrity Servers se utilizan con más frecuencia..

El puerto de Itanium se logró mediante el uso de código fuente mantenido en común dentro de la biblioteca de código fuente de OpenVMS Alpha, con la adición de código condicional y módulos adicionales donde se requerían cambios específicos para Itanium. Esto requería que ciertas dependencias arquitectónicas de OpenVMS fueran reemplazadas o emuladas en el software. Algunos de los cambios incluyeron el uso de la interfaz de firmware extensible (EFI) para iniciar el sistema operativo, la reimplementación de la funcionalidad proporcionada anteriormente por Alpha PALcode dentro del kernel, el uso de nuevos formatos de archivos ejecutables (formato ejecutable y de enlace y DWARF) y la adopción de IEEE 754 como el formato de coma flotante predeterminado.

Al igual que con el puerto de VAX a Alpha, se puso a disposición un traductor binario para Alpha a Itanium, lo que permitió que el software OpenVMS Alpha en modo de usuario se transfiriera a Itanium en situaciones en las que no era posible volver a compilar el código fuente. Este traductor se conoce como Alpha Environment Software Translator (AEST), y también admitía la traducción de ejecutables VAX que ya se habían traducido con VEST.

Dos versiones de preproducción, OpenVMS I64 V8.0 y V8.1, estuvieron disponibles el 30 de junio de 2003 y el 18 de diciembre de 2003. Estas versiones estaban destinadas a organizaciones de HP y proveedores externos involucrados en la migración de software. paquetes a OpenVMS I64. La primera versión de producción, V8.2, se lanzó en febrero de 2005. V8.2 también se lanzó para Alpha, las versiones posteriores de OpenVMS V8.x han mantenido la paridad de funciones entre las arquitecturas Alpha e Itanium.

Puerto a x86-64

Cuando VMS Software Inc. (VSI) anunció que había obtenido los derechos para desarrollar el sistema operativo OpenVMS de HP, también anunció su intención de migrar OpenVMS a la arquitectura x86-64. El esfuerzo de portabilidad se llevó a cabo simultáneamente con el establecimiento de la empresa, así como con el desarrollo de las versiones Itanium y Alpha de OpenVMS V8.4-x de VSI.

El puerto x86-64 está destinado a servidores específicos de HPE y Dell, así como a ciertos hipervisores de máquinas virtuales. El soporte inicial estaba destinado a KVM y VirtualBox. El soporte para VMware se anunció en 2020 y Hyper-V se ha descrito como un objetivo futuro. En 2021, se demostró que el puerto x86-64 se ejecuta en una computadora de placa única basada en Intel Atom.

Al igual que con los puertos Alpha e Itanium, el puerto x86-64 realizó algunos cambios para simplificar la portabilidad y la compatibilidad con OpenVMS en la nueva plataforma, entre ellos: reemplazar el backend del compilador GEM patentado que usan los compiladores VMS con LLVM, cambiar el proceso de arranque para que que OpenVMS se inicia desde un disco de memoria y simular los cuatro niveles de privilegio de OpenVMS en el software, ya que OpenVMS solo puede usar dos de los niveles de privilegio de x86-64.

El primer inicio se anunció el 14 de mayo de 2019. Esto implicó iniciar OpenVMS en VirtualBox y ejecutar con éxito el comando DIRECTORY. En mayo de 2020, el lanzamiento del kit de primeros usuarios V9.0 se puso a disposición de una pequeña cantidad de clientes. Esto consistía en que el sistema operativo OpenVMS se ejecutaba en una máquina virtual VirtualBox con ciertas limitaciones: lo más significativo era que había pocos productos en capas disponibles y el código solo se puede compilar para x86-64 usando compiladores cruzados que se ejecutan en sistemas OpenVMS basados en Itanium. Después del lanzamiento de V9.0, VSI lanzó una serie de actualizaciones mensuales o bimensuales que agregaron funcionalidad adicional y soporte de hipervisor. Estos fueron designados V9.0-A a V9.0-H. En junio de 2021, VSI lanzó la prueba de campo V9.1 y la puso a disposición de los clientes y socios de VSI. V9.1 se envió como una imagen ISO que se puede instalar en una variedad de hipervisores y en servidores HPE ProLiant DL380 a partir de la versión V9.1-A.

OpenVMS 9.2 para x86-64 alcanzó la disponibilidad general el 14 de julio de 2022.

Influencia

Durante la década de 1980, se pretendía que el sistema operativo MICA para la arquitectura PRISM fuera el eventual sucesor de VMS. MICA fue diseñado para mantener la compatibilidad con versiones anteriores de las aplicaciones VMS y, al mismo tiempo, admitir aplicaciones Ultrix sobre el mismo kernel. MICA finalmente se canceló junto con el resto de la plataforma PRISM, lo que llevó a Dave Cutler a dejar DEC por Microsoft. En Microsoft, Cutler dirigió la creación del sistema operativo Windows NT, que se inspiró en gran medida en la arquitectura de MICA. Como resultado, VMS se considera un ancestro de Windows NT, junto con RSX-11, VAXELN y MICA, y existen muchas similitudes entre VMS y NT.

Un proyecto ya desaparecido llamado FreeVMS intentó desarrollar un sistema operativo de código abierto siguiendo las convenciones de VMS. FreeVMS se creó sobre el microkernel L4 y admitió la arquitectura x86-64. El trabajo previo que investigaba la implementación de VMS utilizando una arquitectura basada en microkernel había sido realizado previamente como un ejercicio de creación de prototipos por parte de los empleados de DEC con la asistencia de la Universidad Carnegie Mellon utilizando el microkernel Mach 3.0 adaptado al hardware VAXstation 3100, adoptando un modelo arquitectónico multiservidor.

Arquitectura

La arquitectura del sistema operativo OpenVMS, demostrando las capas del sistema, y los modos de acceso en los que normalmente funcionan

El sistema operativo OpenVMS tiene una arquitectura en capas, que consta de un ejecutivo privilegiado, un intérprete de lenguaje de comandos con privilegios intermedios y utilidades y bibliotecas de tiempo de ejecución (RTL) sin privilegios. El código sin privilegios generalmente invoca la funcionalidad del Ejecutivo a través de servicios del sistema (equivalente a las llamadas al sistema en otros sistemas operativos).

OpenVMS' las capas y los mecanismos se construyen en torno a ciertas características de la arquitectura VAX, que incluyen:

• Disponibilidad de cuatro modos de acceso de procesadores (nombre Kernel, Executive, Supervisor y Usuario, para disminuir el privilegio). Cada modo tiene su propia pila, y cada página de memoria puede tener protecciones de memoria especificadas por movimiento.
• Un espacio de dirección virtual que se divide entre secciones de proceso-espacio privado, y secciones de espacio del sistema que son comunes a todos los procesos.
• 32 interrumpen los niveles prioritarios utilizados para la sincronización.
• Soporte de hardware para la entrega de trampas de sistema asincrónico a procesos.

Estos mecanismos de arquitectura VAX se implementan en Alpha, Itanium y x86-64 mediante la asignación a los mecanismos de hardware correspondientes en esas arquitecturas o mediante la emulación (a través de PALcode en Alpha o en software en Itanium y x86-64).

Ejecutivo y Núcleo

OpenVMS Executive comprende el código privilegiado y las estructuras de datos que residen en el espacio del sistema. El Ejecutivo se subdivide a su vez entre el Kernel, que consiste en el código que se ejecuta en el modo de acceso al kernel, y el código menos privilegiado fuera del Kernel que se ejecuta en el modo de acceso ejecutivo.

Los componentes del Ejecutivo que se ejecutan en el modo de acceso ejecutivo incluyen los Servicios de administración de registros y ciertos servicios del sistema, como la activación de imágenes. La principal distinción entre los modos de acceso kernel y ejecutivo es que la mayoría de las estructuras de datos centrales del sistema operativo se pueden leer desde el modo ejecutivo, pero requieren que se escriba en el modo kernel. El código que se ejecuta en modo ejecutivo puede cambiar al modo kernel a voluntad, lo que significa que la barrera entre el kernel y los modos ejecutivos pretende ser una protección contra la corrupción accidental en lugar de un mecanismo de seguridad.

El Kernel comprende las estructuras de datos centrales del sistema operativo (por ejemplo, tablas de páginas, la base de datos de E/S y datos de programación) y las rutinas que operan en estas estructuras. Por lo general, se describe que el kernel tiene tres subsistemas principales: E/S, gestión de procesos y tiempo, gestión de memoria. Además, dentro del Kernel se implementan otras funciones, como la gestión de nombres lógicos, la sincronización y el envío de servicios del sistema.

OpenVMS permite que el código de modo de usuario con privilegios adecuados cambie al modo ejecutivo o kernel utilizando los servicios del sistema $CMEXEC y $CMKRNL, respectivamente. Esto permite que el código fuera del espacio del sistema tenga acceso directo a las rutinas y los servicios del sistema del Ejecutivo. Además de permitir extensiones de terceros para el sistema operativo, las utilidades principales del sistema operativo utilizan imágenes privilegiadas para manipular las estructuras de datos del sistema operativo a través de interfaces no documentadas.

Sistema de archivos

La interfaz típica de usuario y aplicación en el sistema de archivos es Record Management Services (RMS), aunque las aplicaciones pueden interactuar directamente con el sistema de archivos subyacente a través de los servicios del sistema QIO. Los sistemas de archivos admitidos por VMS se denominan Files-11 On-Disk Structures (ODS), los más importantes de los cuales son ODS-2 y ODS -5. VMS también puede acceder a archivos en CD-ROM ISO 9660 y cintas magnéticas con etiquetas de cinta ANSI.

Files-11 está limitado a volúmenes de 2 TiB. DEC intentó reemplazarlo con un sistema de archivos de sistema de archivos con estructura de registro llamado Spiralog lanzado por primera vez en 1995. Sin embargo, Spiralog se suspendió debido a una variedad de problemas, incluidos problemas con el manejo de volúmenes completos. En cambio, se ha discutido la posibilidad de trasladar el sistema de archivos GFS2 de código abierto a OpenVMS.

Intérprete de lenguaje de comandos

Un intérprete de lenguaje de comandos (CLI) de OpenVMS implementa una interfaz de línea de comandos para OpenVMS; responsable de ejecutar comandos individuales, así como procedimientos de comando (equivalentes a scripts de shell o archivos por lotes). La CLI estándar para OpenVMS es el lenguaje de comandos DIGITAL, aunque también hay otras opciones disponibles.

A diferencia de los shells de Unix, que normalmente se ejecutan en su propio proceso aislado y se comportan como cualquier otro programa de modo de usuario, las CLI de OpenVMS son un componente opcional de un proceso, que existe junto con cualquier imagen ejecutable que ese proceso pueda ejecutar. Mientras que un shell de Unix normalmente ejecutará ejecutables mediante la creación de un proceso separado mediante fork-exec, una CLI de OpenVMS normalmente cargará la imagen ejecutable en el mismo proceso, transferirá el control a la imagen y garantizará que el control se transfiera de nuevo a la CLI una vez que la imagen ha salido y que el proceso vuelve a su estado original.

Debido al hecho de que la CLI se carga en el mismo espacio de direcciones que el código de usuario, y que la CLI es responsable de invocar la activación de la imagen y el resumen de la imagen, la CLI se asigna al espacio de direcciones del proceso en el modo de acceso del supervisor: un mayor nivel de privilegio que la mayoría de los códigos de usuario. Esto es para evitar la manipulación accidental o malintencionada del código y las estructuras de datos de la CLI por parte del código de modo de usuario.

Características

VAXstation 4000 modelo 96 en funcionamiento OpenVMS V6.1, DECwindows Motif y el navegador Mosaico NCSA

Agrupación

OpenVMS admite la agrupación en clústeres (primero llamado VAXcluster y más tarde VMScluster), donde varias computadoras ejecutan su propia instancia del sistema operativo. Las computadoras agrupadas (nodos) pueden ser totalmente independientes entre sí o pueden compartir dispositivos como unidades de disco e impresoras. La comunicación entre nodos proporciona una abstracción de imagen de sistema única. Los nodos se pueden conectar entre sí mediante una conexión de hardware patentada llamada Interconexión de clúster o mediante una LAN Ethernet estándar.

OpenVMS admite hasta 96 nodos en un solo clúster. También permite clústeres de arquitectura mixta. (Las computadoras VAX, Alpha e Itanium tienen cada una una arquitectura diferente). Los clústeres de OpenVMS permiten que las aplicaciones funcionen durante interrupciones planificadas o no planificadas. Las interrupciones planificadas incluyen actualizaciones de hardware y software.

Redes

El conjunto de protocolos DECnet está estrechamente integrado en VMS, lo que permite inicios de sesión remotos, así como acceso transparente a archivos, impresoras y otros recursos en sistemas VMS a través de una red. Las versiones modernas de VMS son compatibles con el protocolo DECnet Fase IV tradicional, así como con la Fase V compatible con OSI (también conocida como DECnet-Plus). El soporte para TCP/IP lo proporciona el producto en capas opcional Servicios TCP/IP para OpenVMS (originalmente conocido como VMS/ULTRIX Connection, luego como ULTRIX Communications Extensiones o UCX). Los servicios TCP/IP se basan en un puerto de la pila de red BSD para OpenVMS, junto con soporte para protocolos comunes como SSH, DHCP, FTP y SMTP.

DEC vendió un paquete de software llamado PATHWORKS (originalmente conocido como Arquitectura de sistemas de computadoras personales o PCSA) que permitía que las computadoras personales con MS-DOS, Microsoft Windows o OS/2, o Apple Macintosh servir como terminal para sistemas VMS, o para usar sistemas VMS como un archivo o servidor de impresión. Posteriormente, PATHWORKS pasó a llamarse Servidor avanzado para OpenVMS y finalmente se reemplazó con un puerto VMS de Samba en el momento del puerto de Itanium.

DEC proporcionaba el protocolo de transporte de área local (LAT) que permitía conectar terminales e impresoras remotas a un sistema VMS a través de un servidor de terminal como uno de la familia DECserver.

Programación

DEC (y sus empresas sucesoras) proporcionaron una amplia variedad de lenguajes de programación para VMS. Los idiomas admitidos oficialmente en VMS, ya sean actuales o históricos, incluyen:

Entre las características notables de OpenVMS se encuentra el Common Language Environment, un estándar estrictamente definido que especifica convenciones de llamada para funciones y rutinas, incluido el uso de pilas, registros, etc., independientemente de la programación. idioma. Debido a esto, es posible llamar a una rutina escrita en un idioma (por ejemplo, Fortran) desde otro (por ejemplo, COBOL), sin necesidad de conocer los detalles de implementación del idioma de destino. OpenVMS en sí mismo se implementa en una variedad de idiomas diferentes y el entorno de idioma común y el estándar de llamadas admite la combinación libre de estos idiomas. DEC creó una herramienta denominada Lenguaje de definición de estructuras (SDL), que permitía generar definiciones de tipos de datos para diferentes idiomas a partir de una definición común.

Herramientas de desarrollo

El "Gran Muro" de la documentación VAX/VMS, en Living Computers: Museo + Laboratorios

DEC proporcionó una colección de herramientas de desarrollo de software en un producto en capas llamado DECset (originalmente llamado VAXset). Este constaba de las siguientes herramientas:

• Language-Sensitive Editor (LSE)
• Code Management System (CMS) un sistema de control de versiones
• Sistema de gestión de módulos (MMS), una herramienta de construcción
• el Fuente Code Analyzer (Analyzer)SCA), un analizador estático
• el Análisis de rendimiento y cobertura ()PCA), un perfilador
• Digital Test Manager (DTM), como gestor de pruebas
• Además, varios editores de texto están incluidos en el sistema operativo, incluyendo EDT, EVE y TECO.

El depurador de OpenVMS admite todos los compiladores DEC y muchos lenguajes de terceros. Permite puntos de interrupción, puntos de observación y depuración de programas de tiempo de ejecución interactivos, ya sea mediante una línea de comandos o una interfaz gráfica de usuario. Se pueden usar un par de depuradores de nivel inferior, llamados DELTA y XDELTA, para depurar código privilegiado además del código de aplicación normal.

En 2019, VSI lanzó un entorno de desarrollo integrado con soporte oficial para VMS basado en Visual Studio Code. Esto permite desarrollar y depurar aplicaciones VMS de forma remota desde una estación de trabajo Microsoft Windows, macOS o Linux.

Gestión de bases de datos

DEC creó una serie de productos de base de datos opcionales para VMS, algunos de los cuales se comercializaron como la familia VAX Information Architecture. Estos productos incluyen:

• Rdb – Un sistema de base de datos relacional que utilizaba originalmente el propietario Operador de datos relacionales (RDO) interfaz de consulta, pero más tarde ganó el soporte SQL.
• DBMS – Un sistema de gestión de bases de datos que utiliza el modelo de red CODASYL Manipulación de datos Idioma (DML).
• Digital Standard MUMPS (DSM) – una base de datos de lenguaje de programación integrada y valor clave.
• Diccionario de datos comunes (CDD) – un repositorio central de esquemas de bases de datos, que permitió que los esquemas fueran compartidos entre diferentes aplicaciones, y que se generaran definiciones de datos para diferentes lenguajes de programación.
• DATATRIEVE – una herramienta de consulta e información que podría acceder a datos de archivos RMS, así como bases de datos Rdb y DBMS.
• Sistema de Gestión de Control de Aplicaciones (ACMS) – Un monitor de procesamiento de transacciones, que permite crear aplicaciones utilizando un alto nivel Descripción de la tarea Idioma (TDL). Los pasos individuales de una transacción se pueden implementar utilizando comandos DCL, o procedimientos de lenguaje común. Las interfaces de usuario se pueden implementar utilizando TDMS, DECforms o el producto de automatización de oficinas ALL-IN-1 de Digital.
• RALLY, DECadmire – Lenguas de programación de cuarta generación (4GL) para generar aplicaciones respaldadas por bases de datos. DECadmire contó con la integración con ACMS, y posteriormente proporcionó soporte para generar aplicaciones Visual Basic cliente-servidor para Windows PCs.

En 1994, DEC vendió Rdb, DBMS y CDD a Oracle, donde permanecen en desarrollo activo. En 1995, DEC vendió DSM a InterSystems, que lo rebautizó como Open M y finalmente lo reemplazó con su producto Caché.

Los ejemplos de sistemas de administración de bases de datos de terceros para OpenVMS incluyen MariaDB, Mimer SQL y System 1032.

Interfaces de usuario

OpenVMS Alpha V8.4-2L1, mostrando el CLI DCL en una sesión terminal

VMS se diseñó originalmente para usarse y administrarse de forma interactiva mediante terminales de video basados en texto de DEC, como el VT100, o terminales impresos, como la serie DECwriter. Desde la introducción de la línea VAXstation en 1984, VMS ha admitido opcionalmente interfaces gráficas de usuario para usar con estaciones de trabajo o terminales X como la serie VT1000.

Interfaces de usuario basadas en texto

El lenguaje de comandos DIGITAL (DCL) ha servido como el principal intérprete de lenguaje de comandos (CLI) de OpenVMS desde el primer lanzamiento. Otras CLI oficiales disponibles para VMS incluyen el RSX-11 MCR (solo VAX) y varios shells de Unix. DEC proporcionó herramientas para crear aplicaciones de interfaz de usuario basadas en texto: el Sistema de gestión de formularios (FMS) y el Sistema de gestión de datos de terminal (TDMS), más tarde sucedido por DECforms. También existe una interfaz de nivel inferior llamada Screen Management Services (SMG$), comparable a las maldiciones de Unix.

Interfaces gráficas de usuario

VWS 4.5 se ejecuta en la parte superior de VAX/VMS V5.5-2

DECwindows XUI gestor de ventana que se ejecuta en la parte superior de VAX/VMS V5.5-2

A lo largo de los años, VMS ha pasado por varios conjuntos de herramientas e interfaces GUI diferentes:

• La interfaz gráfica original de usuario para VMS era un sistema de ventana patentado conocido como VMS Workstation Software (VWS), que fue liberado por primera vez para la VAXstation I en 1984. Expuso una API llamada los servicios de interfaz de usuario (UIS). Corrió en una selección limitada de hardware VAX.
• En 1989, el DEC reemplazó el VWS con un nuevo sistema de ventana basado en X11 llamado DECwindows. Fue incluido por primera vez en VAX/VMS V5.1. Las versiones tempranas de DECwindows incluían una interfaz construida sobre un toolkit propietario llamado X Interfaz de usuario (XUI). Se proporcionó un producto con capas llamado UISX para permitir que las aplicaciones VWS/UIS funcionen en la parte superior de DECwindows. Las partes de XUI fueron utilizadas posteriormente por la Open Software Foundation como la base del kit de herramientas Motif.
• En 1991, el DEC reemplazó XUI con el kit de herramientas Motif, creando DECwindows Motif. Como resultado, el Motif Window Manager se convirtió en la interfaz de DECwindows predeterminada en OpenVMS V6.0, aunque el gestor de ventana XUI permaneció como una opción.
• En 1996, como parte de OpenVMS V7.1, DEC lanzó el Nuevo escritorio interfaz para DECwindows Motif, basado en el entorno de escritorio común (CDE). En sistemas Alpha e Itanium, todavía es posible seleccionar la UI más antigua basada en MWM (conferida como el "DeCwindows Desktop") en el momento de inicio de sesión. El Nuevo Escritorio nunca fue portado a las versiones VAX de OpenVMS.

Las versiones de VMS que se ejecutaban en estaciones de trabajo DEC Alpha en la década de 1990 admitían adaptadores de gráficos OpenGL y Accelerated Graphics Port (AGP). VMS también brinda soporte para estándares de gráficos más antiguos, como GKS y PHIGS. Las versiones modernas de DECwindows se basan en X.Org Server.

Seguridad

OpenVMS proporciona varias funciones y mecanismos de seguridad, incluidos identificadores de seguridad, identificadores de recursos, identificadores de subsistemas, ACL, detección de intrusos y alarmas y auditorías de seguridad detalladas. Versiones específicas evaluadas en Trusted Computer System Evaluation Criteria Class C2 y, con la versión mejorada de seguridad SEVMS en Class B1. OpenVMS también tiene una calificación ITSEC E3 (ver NCSC y Common Criteria). Las contraseñas se codifican mediante el polinomio de Purdy.

Vulnerabilidades

• Las primeras versiones de VMS incluyeron varias cuentas de usuario privilegiadas (incluyendo SYSTEM, FIELD, SYSTEST y DECNET) con contraseñas predeterminadas que a menudo fueron dejados sin cambios por los administradores del sistema. Un número de gusanos informáticos para VMS incluyendo el gusano WANK y el gusano de Navidad Padre explotaron estas contraseñas predeterminadas para obtener acceso a nodos en las redes DECnet. Este tema también fue descrito por Clifford Stoll en El huevo del cuco como medio por el cual Markus Hess obtuvo acceso no autorizado a sistemas VAX/VMS. En V5.0 se eliminaron las contraseñas predeterminadas y se hizo obligatorio proporcionar contraseñas para estas cuentas durante la configuración del sistema.
• En 2017 se descubrió una vulnerabilidad de 33 años en VMS en VAX y Alpha y se asignó el ID CVE CVE-2017-17482. En las plataformas afectadas, esta vulnerabilidad permitió a un atacante con acceso a la línea de comandos DCL realizar un ataque de escalada de privilegios. La vulnerabilidad se basa en la explotación de un error de desbordamiento de buffer en el código de procesamiento de comandos DCL, la capacidad de un usuario para interrumpir una imagen de ejecución (programa ejecutable) con CTRL/Y y volver al impulso DCL, y el hecho de que DCL conserva los privilegios de la imagen interrumpida. El error de desbordamiento de buffer permitió ejecutar el código de shell con los privilegios de una imagen interrumpida. Esto podría utilizarse junto con una imagen instalada con privilegios más altos que la cuenta del atacante para evitar la seguridad del sistema.

Compatibilidad con POSIX

Se crearon varias capas oficiales de compatibilidad con Unix y POSIX para VMS. El primero de los cuales fue DEC/Shell, que era un producto en capas que consistía en puertos de la versión 7 Unix Bourne shell y varias otras utilidades de Unix para VAX/VMS. En 1992, DEC lanzó el producto en capas POSIX para OpenVMS, que incluía un shell basado en Korn Shell. POSIX para OpenVMS fue reemplazado posteriormente por el proyecto de código abierto GNV (GNU's not VMS), que se incluyó por primera vez en los medios de OpenVMS en 2002. Entre otras herramientas de GNU, GNV incluye un puerto del Bash shell a VMS. Ejemplos de capas de compatibilidad de Unix de terceros para VMS incluyen Eunice.

Programas para aficionados

En 1997, OpenVMS y una serie de productos en capas se pusieron a disposición de forma gratuita para aficionados, uso no comercial como parte del Programa de aficionados de OpenVMS. Desde entonces, varias empresas que producen software OpenVMS han puesto a disposición sus productos bajo los mismos términos, como Process Software. Antes del puerto x86-64, la antigüedad y el costo del hardware capaz de ejecutar OpenVMS hicieron que los emuladores como SIMH fueran una opción común para las instalaciones de los aficionados.

En marzo de 2020, HPE anunció el fin del programa Hobbyist de OpenVMS. A esto le siguió el anuncio de VSI del Community License Program (CLP) en abril de 2020, que pretendía reemplazar al HPE Hobbyist Program. El CLP se lanzó en julio de 2020 y proporciona licencias para versiones de VSI OpenVMS en sistemas Alpha e Integrity. Las licencias de OpenVMS x86-64 estarán disponibles cuando se lance una versión estable para esta arquitectura. OpenVMS para VAX no está cubierto por el CLP, ya que no hay versiones de VSI de OpenVMS VAX, y las versiones anteriores siguen siendo propiedad de HPE.

Historial de versiones