Máquina virtual (sistema operativo)

VM (a menudo: VM/CMS) es una familia de sistemas operativos de máquinas virtuales de IBM que se utilizan en mainframes de IBM System/370, System/390, zSeries, System z y sistemas compatibles, incluido el emulador Hercules para computadoras personales.

Se conocen las siguientes versiones:

Virtual Machine Facility/370

VM/370, lanzado en 1972, es una implementación System/370 del anterior sistema operativo CP/CMS.

VM/370 Programa de extensiones básicas del sistema Producto

VM/BSE (BSEPP) es una mejora para VM/370 que añade soporte para más dispositivos (como unidades DASD de arquitectura fija de 3370 tipos), mejoras en el entorno CMS (como un editor mejorado), y algunas mejoras de estabilidad a CP.

Programa de extensiones de sistema VM/370 Producto

VM/SE (SEPP) es una mejora para VM/370 que incluye las instalaciones de VM/BSE, así como algunas correcciones y características adicionales.

Máquina Virtual / Producto de sistema

VM/SP, una versión de hito, reemplaza VM/370, VM/BSE y VM/SE. Lanzamiento 1 añadido EXEC2 y XEDIT System Editor de productos; Lanzamiento 3 añadido REXX; Lanzamiento 6 agregó el sistema de archivos compartido.

Máquina Virtual / Producto de sistema Opción de alto rendimiento

VM/SP HPO añade soporte y funcionalidad de dispositivo adicional a VM/SP, y permite que ciertas máquinas S/370 que pueden utilizar más de 16 MB de almacenamiento real para hacerlo, hasta 64 MB. Esta versión estaba destinada a usuarios que estarían ejecutando múltiples invitados S/370 a la vez.

Virtual Machine/Extended Architecture Migration Aid

VM/XA MA tiene como objetivo facilitar la migración de MVS/370 a MVS/XA permitiendo que ambos funcionen simultáneamente en el mismo complejo procesador.

Máquina Virtual / Instalación del Sistema de Arquitectura

VM/XA SF es un VM/XA MA actualizado con mejor funcionalidad y rendimiento.

Máquina Virtual / Sistema de Arquitectura

VM/XA SP es un VM/XA MA actualizado con mejor funcionalidad y rendimiento, ofrecido como reemplazo para VM/SP HPO en máquinas que soportan S/370-XA. Incluye una versión de CMS que puede funcionar en modo S/370 o S/370-XA.

Virtual Machine/Enterprise Systems Architecture

VM/ESA proporciona las instalaciones de VM/SP, VM/SP HPO y VM/XA SP. VM/ESA versión 1 puede funcionar en modo S/370, ESA/370 o ESA/390; no admite el modo S/370 XA. La versión 2 solo funciona en modo ESA/390. Las versiones S/370 de VM/ESA fueron en realidad su propia versión separada de las versiones ESA/390 de VM/ESA, ya que las versiones S/370 se basan en la base de código VM/SP HPO más antigua, y las versiones ESA/390 se basan en la base de código VM/XA más reciente.

z/VM

z/VM, la última versión todavía ampliamente utilizada como una de las principales soluciones de virtualización completa para el mercado de mainframe. z/VM 4.4 fue la última versión que podría funcionar en modo ESA/390; versiones posteriores sólo funcionan en modo z/Architecture.

El CMS en el nombre se refiere al Sistema de Monitoreo Conversacional, un componente del producto que es un sistema operativo de un solo usuario que se ejecuta en una máquina virtual y proporciona tiempo compartido conversacional en VM.

Resumen

El corazón de la arquitectura de VM es el Programa de Control o hipervisor abreviado CP, VM-CP y, a veces, ambiguamente, máquina virtual. Se ejecuta en el hardware físico y crea el entorno de la máquina virtual. VM-CP proporciona una virtualización completa de la máquina física, incluidas todas las E/S y otras operaciones privilegiadas. Realiza el uso compartido de recursos del sistema, incluida la administración de dispositivos, el despacho, la administración de almacenamiento virtual y otras tareas tradicionales del sistema operativo. A cada usuario de VM se le proporciona una máquina virtual separada que tiene su propio espacio de direcciones, dispositivos virtuales, etc., y que es capaz de ejecutar cualquier software que pueda ejecutarse en una máquina independiente. Un mainframe de VM dado normalmente ejecuta cientos o miles de instancias de máquinas virtuales. VM-CP comenzó su vida como CP-370, una reimplementación de CP-67, en sí misma una reimplementación de CP-40.

Dentro de cada máquina virtual se ejecuta otro sistema operativo, un sistema operativo invitado. Esto podría ser:

• CMS (Conversational Monitor System, renombrado del Sistema Cambridge Monitor de CP/CMS). La mayoría de las máquinas virtuales ejecutan CMS, un sistema operativo ligero y de un solo usuario. Su entorno interactivo es comparable al de un PC de un solo usuario, incluyendo un sistema de archivos, servicios de programación, acceso a dispositivos y procesamiento de línea de comandos. (Mientras que una versión anterior de CMS fue descrita sin duda como "CP/M en un mainframe", la comparación es un anacronismo; el autor de CP/M, Gary Kildall, fue un usuario experimentado de CMS.)
• GCS (Group Control System), que proporciona una simulación limitada de la API MVS. IBM originalmente proporcionó GCS para ejecutar VTAM sin un servicio OS/VS1 máquina virtual y VTAM Communications Network Application (VCNA). RSCS V2 también corrió bajo GCS.
• Un sistema operativo estándar. Los sistemas operativos principales de IBM (por ejemplo, las familias MVS y DOS/VSE, OS/VS1, TSS/370, u otra capa de VM/370 (ver abajo) pueden ser cargados y corredos sin modificaciones. El hipervisor VM trata a los sistemas operativos invitados como programas de aplicación con privilegios excepcionales – les impide utilizar directamente instrucciones privilegiadas (las que permitirían que las aplicaciones se apoderaran de todo el sistema o partes significativas de él), pero simula instrucciones privilegiadas en su nombre. La mayoría de los sistemas operativos mainframe terminan una aplicación normal que intenta usurpar los privilegios del sistema operativo. El hipervisor VM puede simular varios tipos de terminales de consola para el sistema operativo invitado, como la línea de copia dura 3215, la familia gráfica 3270, y la consola integrada en las máquinas System/390 y System Z. Otros usuarios pueden acceder a las máquinas virtuales ejecutadas usando el comando DIAL en la pantalla del logotipo, que conectará su terminal al primer dispositivo emulado 3270 disponible, o el primer dispositivo 2703 disponible si el usuario es DIALing desde una terminal de máquina de escribir.
• Otra copia de VM. A segundo nivel instancia de VM se puede virtualizar completamente dentro de una máquina virtual. Así es como se hace el desarrollo y la prueba del VM (un VM de segundo nivel puede potencialmente implementar un diferentes virtualización del hardware). Esta técnica se utilizó para desarrollar software S/370 antes de que el hardware S/370 estuviera disponible, y ha seguido desempeñando un papel en el nuevo desarrollo de hardware en IBM. La literatura cita ejemplos prácticos de virtualización 5 niveles profundos. Los niveles de VM por debajo de la parte superior también se tratan como aplicaciones pero con privilegios excepcionales.
• Una copia de la versión mainframe de AIX o Linux. En el entorno mainframe, estos sistemas operativos suelen funcionar bajo VM, y se manejan como otros sistemas operativos de invitados. (También pueden funcionar como sistemas operativos "nativos" en el hardware desnudo.) También hubo las versiones IX/370 de corta duración, así como las versiones S/370 y S/390 de AIX (AIX/370 y AIX/ESA).
• Subsistema VM especializado. Varios sistemas no CMS funcionan dentro de máquinas virtuales VM-CP, proporcionando servicios a los usuarios de CMS, como spooling, interprocess communications, special device support, and networking. Funcionan detrás de las escenas, ampliando los servicios disponibles a CMS sin agregar al programa de control VM-CP. Al correr en máquinas virtuales separadas, reciben las mismas protecciones de seguridad y fiabilidad que otros usuarios de VM. Por ejemplo:
  • RSCS (Remote Spooling and Communication Subsystem, aka VNET) – instalaciones de comunicación y transferencia de información entre máquinas virtuales y otros sistemas
  • RACF (Resource Access Control Facility) - a security system
  • Sistema de archivos compartido (SFS), que organiza archivos compartidos en un árbol de directorios (los servidores se denominan comúnmente "VMSERVx"
  • VTAM (Virtual Telecommunications Access Method) – una instalación que proporciona soporte para una red de Arquitectura de Redes de Sistemas
  • PVM (VM/Pass-Through Facility) – una instalación que proporciona acceso remoto a otros sistemas VM
  • TCPIP, SMTP, FTPSERVE, PORTMAP, VMNFS – un conjunto de máquinas de servicio que proporcionan redes TCP/IP a VM/CMS
  • Servidor Db2 para VM – un sistema de bases de datos SQL, los servidores suelen llamarse de forma similar a "SQLMACH" y "SQLMSTR"
  • DIRMAINT – Un sistema simplificado de gestión de directorios de usuarios (el directorio es un listado de cada cuenta en el sistema, incluyendo configuración de hardware virtual, contraseñas de usuario y minidiscos).
  • MUMPS/VM — una implementación de la base de datos MUMPS y lenguaje de programación que podría funcionar como invitado en VM/370. MUMPS/VM fue introducida en 1987 y suspendida en 1991.
• Un sistema operativo modificado o escrito por el usuario, como CSS o VPS/VM de la Universidad de Boston.

Interfaz de hipervisor

IBM acuñó el término hipervisor para el 360/65 y luego lo usó para el controlador DIAG de CP-67.

La instrucción Diagnosticar ('83'x—sin mnemónico) es una instrucción privilegiada originalmente pensada por IBM para realizar " en funciones de diagnóstico u otras funciones dependientes del modelo." IBM reutilizó DIAG para "comunicación entre una máquina virtual y CP." La instrucción contiene dos números de registro de cuatro bits, denominados Rx y Ry, que pueden "contener direcciones de almacenamiento de operandos o códigos de retorno pasados a la interfaz DIAGNOSE" y un código de dos bytes "que el CP usa para determinar qué función de DIAGNÓSTICO debe realizar." Algunas de las funciones de diagnóstico disponibles se enumeran a continuación.

Uso de CMS de DIAGNOSE

En un momento, CMS era capaz de ejecutarse en una máquina desnuda, como un verdadero sistema operativo (aunque tal configuración sería inusual). Ahora se ejecuta solo como un sistema operativo invitado en VM. Esto se debe a que CMS se basa en una interfaz de hipervisor para VM-CP, para realizar operaciones del sistema de archivos y solicitar otros servicios de VM. Esta interfaz de paravirtualización:

• Proporciona un camino rápido a VM-CP, para evitar la sobrecarga de la simulación completa.
• Se desarrolló por primera vez como una mejora de rendimiento para CP/CMS versión 2.1, un hito temprano importante en la eficiencia del CP.
• Utiliza una instrucción de máquina no virtualizada y dependiente de modelos como señal entre CMS y CP: DIAG (diagnose).

Minidiscos

CMS y otros sistemas operativos a menudo tienen requisitos de DASD mucho más pequeños que los tamaños de los volúmenes reales. Por esta razón, CP permite que una instalación defina discos virtuales de cualquier tamaño hasta la capacidad del dispositivo. Para volúmenes CKD, un minidisco debe definirse en cilindros completos. Un minidisco tiene los mismos atributos que el disco real subyacente, excepto que generalmente es más pequeño y el comienzo de cada minidisco se asigna al cilindro o bloque 0. Se puede acceder al minidisco usando los mismos programas de canal que el disco real.

A minidisc that has been initialized with a CMS file system is referred to as aCMS minidisc, although CMS is not the only system that can use them.

Es una práctica común definir minidiscos de volumen completo para que los usen sistemas operativos invitados como z/OS en lugar de usar DEDICATE para asignar el volumen a una máquina virtual específica. Además, los "enlaces de paquete completo" a menudo se definen para cada DASD en el sistema y son propiedad del ID de usuario MAINT. Estos se utilizan para realizar una copia de seguridad del sistema utilizando el programa DASD Dump/Restore, donde todo el contenido de un DASD se graba en cinta (u otro DASD) exactamente.

Sistema de archivos compartidos

VM/SP versión 6 introdujo el sistema de archivos compartidos que mejoró enormemente las capacidades de almacenamiento de archivos de CMS. El sistema de archivos de minidisco CMS no admite directorios (carpetas), sin embargo, el SFS sí lo hace. SFS también introduce una seguridad más granular. Con los minidiscos CMS, el sistema se puede configurar para permitir o denegar a los usuarios acceso de solo lectura o de lectura y escritura a un disco, pero los archivos individuales no pueden tener la misma seguridad. SFS alivia esto y mejora enormemente el rendimiento.

El SFS lo proporcionan las máquinas virtuales de servicio. En un sistema de VM moderno, generalmente se requieren tres: VMSERVR, la "máquina de recuperación" que en realidad no sirve ningún archivo; VMSERVS, el servidor para el grupo de archivos VMSYS; y VMSERVU, el servidor para el grupo de archivos VMSYSU (usuario). Las máquinas del servidor del grupo de archivos poseen varios minidiscos, que generalmente incluyen un disco A CMS (dirección de dispositivo virtual 191, que contiene los archivos de configuración del grupo de archivos), un disco de control, un disco de registro y cualquier cantidad de discos de datos que realmente almacenen archivos de usuario.

Con las versiones modernas de VM, la mayor parte del sistema se puede instalar en SFS, siendo los pocos minidiscos restantes los absolutamente necesarios para que el sistema se inicie, y los que pertenecen a las máquinas del servidor de pools de archivos.

Si una cuenta de usuario está configurada para usar solo SFS (y no posee minidiscos), el disco A del usuario será FILEPOOL:USERID. y cualquier directorio subsiguiente que el el usuario crea será FILEPOOL:USERID.DIR1.DIR2.DIR3 donde la ruta de archivo UNIX equivalente es /dir1/dir2/dir3. Los directorios SFS pueden tener controles de acceso mucho más granulares en comparación con los minidiscos (que, como se mencionó anteriormente, a menudo solo pueden tener una contraseña de lectura, una contraseña de escritura y una contraseña de escritura múltiple). Los directorios SFS también resuelven los problemas que pueden surgir cuando dos usuarios escriben en el mismo minidisco CMS al mismo tiempo, lo que puede causar daños en el disco (ya que la VM CMS que realiza las escrituras puede no saber que otra instancia CMS también está escribiendo en el minidisco).

Las máquinas del servidor del pool de archivos también sirven a un sistema de archivos estrechamente relacionado: el sistema de archivos Byte. BFS se utiliza para almacenar archivos en un sistema de archivos de estilo UNIX. Su uso principal es para el entorno POSIX de VM OpenExtensions para CMS. Las propias máquinas virtuales del usuario de CMS se comunican con las máquinas virtuales del servidor SFS a través del mecanismo IUCV.

Historia

La historia temprana de VM se describe en los artículos CP/CMS e Historia de CP/CMS. VM/370 es una reimplementación de CP/CMS y estuvo disponible en 1972 como parte del anuncio de funciones avanzadas System/370 de IBM (que agregó hardware de memoria virtual y sistemas operativos a la serie System/370). Las primeras versiones de VM hasta VM/370 Release 6 continuaron en código abierto hasta 1981, y hoy en día se consideran de dominio público. Esta política finalizó en 1977 con las actualizaciones con cargo de VM/SE y VM/BSE y en 1980 con VM/Producto del sistema (VM/SP). Sin embargo, IBM continuó brindando actualizaciones en forma de fuente para el código existente durante muchos años, aunque las actualizaciones de todos excepto la base gratuita requerían una licencia. Al igual que con CP-67, las instrucciones privilegiadas en una máquina virtual provocan una interrupción del programa y CP simuló el comportamiento de la instrucción privilegiada.

VM siguió siendo una plataforma importante dentro de IBM, utilizada para el desarrollo del sistema operativo y uso de tiempo compartido; pero para los clientes seguía siendo el 'otro sistema operativo' de IBM. Las familias OS y DOS siguieron siendo los productos estratégicos de IBM y no se animó a los clientes a ejecutar VM. Aquellos que lo hicieron formaron estrechas relaciones de trabajo, continuando con el modelo de apoyo comunitario de los primeros usuarios de CP/CMS. Mientras tanto, el sistema luchó con luchas políticas internas dentro de IBM sobre qué recursos deberían estar disponibles para el proyecto, en comparación con otros esfuerzos de IBM. Se observó un problema básico con el sistema en el nivel de ventas de campo de IBM: VM/CMS demostró que reducía la cantidad de hardware necesario para admitir una cantidad determinada de usuarios de tiempo compartido. Después de todo, IBM estaba en el negocio de vender sistemas informáticos.

Melinda Varian ofrece esta cita fascinante que ilustra el éxito inesperado de VM:

Las previsiones de marketing para VM/370 predijeron que no más de un 168 ejecutaría VM durante toda la vida del producto. De hecho, el primero 168 entregado a un cliente corrió sólo CP y CMS. Diez años más tarde, el diez por ciento de los grandes procesadores que se envían de Poughkeepsie estaría destinado a ejecutar VM, como una parte muy sustancial de las máquinas de gama media que fueron construidas en Endicott. Antes de que hubieran pasado quince años, habría más licencias de VM que licencias de MVS.

Una versión de DOS para PC que ejecuta CMS en el XT/370 (y más tarde en el AT/370) se llama VM/PC. VM/PC 1.1 se basó en VM/SP versión 3. Cuando IBM presentó las tarjetas de procesador P/370 y P/390, una PC ahora podía ejecutar sistemas VM completos, incluidos VM/370, VM/SP, VM/XA y VM/ESA (estas tarjetas eran totalmente compatibles con los mainframes S/370 y S/390 y podían ejecutar cualquier sistema operativo S/370 de la era de 31 bits, por ejemplo, MVS/ESA, VSE/ESA).

Además de las versiones básicas de VM/SP, IBM también presentó VM/SP HPO (opción de alto rendimiento). Este complemento (que se instala sobre la versión base de VM/SP) mejoró varias funciones clave del sistema, lo que incluye permitir el uso de más de 16 MB de almacenamiento (RAM) en modelos compatibles (como IBM 4381). Con VM/SP HPO instalado, el nuevo límite era de 64 MB; sin embargo, un solo usuario (o máquina virtual) no podía usar más de 16 MB. También se mejoraron las funciones del sistema de archivos de spool, lo que permitió crear 9900 archivos de spool por usuario, en lugar de 9900 para todo el sistema. La arquitectura del sistema de archivos de spool también se mejoró, cada archivo de spool ahora tenía una ID de usuario única asociada con él, y los bloques de control de archivos del lector ahora se guardaban en almacenamiento virtual. El sistema también podría configurarse para denegar a ciertos usuarios el acceso a la función de vectores (mediante entradas en el directorio de usuarios).

Las versiones de VM desde VM/SP Release 1 admiten sistemas multiprocesador. Las versiones System/370 de VM (como VM/SP y VM/SP HPO) admitían un máximo de dos procesadores, con el sistema funcionando en modo UP (monoprocesador), modo MP (multiprocesador) o modo AP (procesador adjunto). El modo AP es el mismo que el modo MP, excepto que el segundo procesador carece de capacidad de E/S. Las versiones System/370-XA de VM (como VM/XA) admitieron más. Las versiones System/390 (como VM/ESA) casi eliminaron el límite por completo, y algunos sistemas z/VM modernos pueden tener hasta 80 procesadores. El límite por máquina virtual para los procesadores definidos es 64.

Cuando IBM introdujo System/370 Extended Architecture en el 3081, los clientes se enfrentaron a la necesidad de ejecutar un sistema MVS/370 de producción mientras probaban MVS/XA en la misma máquina. La solución de IBM fue VM/XA Migration Aid, que utilizaba la nueva instrucción Start Interpretive Execution (SIE) para ejecutar la máquina virtual. SIE manejó automáticamente algunas instrucciones privilegiadas y regresó a CP para los casos que no pudo manejar. El administrador del sistema/recursos del procesador (PR/SM) del último 3090 también usaba SIE. Hubo varios productos VM/XA antes de que finalmente fueran reemplazados por VM/ESA y z/VM.

Además de las redes RSCS, IBM también proporcionó a los usuarios redes VTAM. ACF/VTAM para VM era totalmente compatible con ACF/VTAM en MVS y VSE. Al igual que RSCS, VTAM en VM se ejecutó bajo el sistema operativo especializado GCS. Sin embargo, VM también admitía redes TCP/IP. A fines de la década de 1980, IBM produjo una pila TCP/IP para VM/SP y VM/XA. La pila admitía redes IPv4 y una variedad de sistemas de interfaz de red (como enlaces de canal a canal entre mainframe o una PC IBM RT especializada que retransmitiría el tráfico a una red Token Ring o Ethernet). La pila proporcionó soporte para conexiones Telnet, desde emuladores de terminal de modo de línea simple o emuladores compatibles con VT100, o emuladores de terminal IBM 3270 adecuados. La pila también proporcionó un servidor FTP. IBM también produjo un servidor NFS opcional para VM; las primeras versiones eran bastante primitivas, pero las versiones modernas son mucho más avanzadas.

También había una cuarta opción de red, conocida como VM/Pass-Through Facility (o más comúnmente llamado, PVM). PVM, como VTAM, permitía conexiones a sistemas VM/CMS remotos, así como a otros sistemas IBM. Si dos nodos de VM/CMS estuvieran vinculados a través de un enlace de canal a canal o un enlace bisync (posiblemente usando un módem de acceso telefónico o una línea alquilada), un usuario podría conectarse de forma remota a cualquiera de los sistemas ingresando "DIAL PVM" en la pantalla de inicio de sesión de la VM, luego ingrese el nombre del nodo del sistema (o selecciónelo de una lista de nodos disponibles). Alternativamente, un usuario que ejecuta CMS podría usar el programa PASSTHRU que se instaló junto con PVM, lo que permite un acceso rápido a los sistemas remotos sin tener que cerrar la sesión del usuario. PVM también admitió el acceso a sistemas que no son VM, utilizando una técnica de emulación 3x74. Las versiones posteriores de PVM también presentaban un componente que podía aceptar conexiones desde una red SNA.

VM también fue el sistema operativo fundamental de BITNET, ya que el sistema RSCS disponible para VM proporcionó una red simple que fue fácil de implementar y algo confiable. Los sitios de VM estaban interconectados por medio de una VM de RSCS en cada sistema de VM que se comunicaba entre sí, y los usuarios podían enviar y recibir mensajes, archivos y trabajos por lotes a través de RSCS. La "NOTA" El comando usó XEDIT para mostrar un cuadro de diálogo para crear un correo electrónico, desde el cual el usuario podría enviarlo. Si el usuario especificó una dirección en forma de usuario en el nodo, el archivo de correo electrónico se enviaría a RSCS, que luego lo enviaría al usuario de destino en el sistema de destino. Si el sitio tiene TCP/IP instalado, RSCS podría funcionar con la máquina de servicio SMTP para enviar notas (correos electrónicos) a sistemas remotos, así como para recibirlos. Si el usuario especificó user at some.host.name, el programa NOTE entregaría el correo electrónico a la máquina de servicio SMTP, que luego lo enrutaría al sitio de destino en Internet.

La función de la máquina virtual cambió dentro de IBM cuando la evolución del hardware condujo a cambios significativos en la arquitectura del procesador. La compatibilidad con versiones anteriores siguió siendo la piedra angular de la familia de mainframe de IBM, que aún utiliza el conjunto de instrucciones básico introducido con el System/360 original; pero la necesidad de un uso eficiente de zSeries de 64 bits hizo que el enfoque de VM fuera mucho más atractivo. VM también se utilizó en centros de datos que se convirtieron de DOS/VSE a MVS y es útil cuando se ejecutan mainframes AIX y Linux, plataformas que iban a ser cada vez más importantes. La plataforma z/VM actual finalmente logró el reconocimiento dentro de IBM que los usuarios de VM sintieron durante mucho tiempo que se merecía. Algunos sitios z/VM ejecutan miles de usuarios de máquinas virtuales simultáneos en un solo sistema. z/VM se lanzó por primera vez en octubre de 2000 y permanece en uso y desarrollo activos.

IBM y terceros han ofrecido muchas aplicaciones y herramientas que se ejecutan bajo VM. Los ejemplos incluyen RAMIS, FOCUS, SPSS, NOMAD, DB2, REXX, RACF y OfficeVision. Las ofertas actuales de VM ejecutan toda la gama de aplicaciones de mainframe, incluidos servidores HTTP, administradores de bases de datos, herramientas de análisis, paquetes de ingeniería y sistemas financieros.

Comandos CP

A partir de la versión 6, el programa de control VM/370 tiene varios comandos para usuarios generales relacionados con la definición y el control de la máquina virtual del usuario. Las partes en minúsculas del comando son opcionales

Extensiones de edición abierta

A partir de la versión 2 de VM/ESA, IBM introdujo la característica opcional de pago OpenEdition para VM/ESA Shell and Utilities Feature, que brinda compatibilidad con POSIX para CMS. La característica sobresaliente fue un shell UNIX para CMS. El compilador C para este entorno UNIX lo proporciona C/370 o C para VM/ESA. Ni el sistema de archivos CMS ni el sistema de archivos compartidos de VM estándar tienen soporte para rutas y archivos de estilo UNIX; en su lugar, se utiliza el sistema de archivos de bytes. Una vez que se crea una extensión BFS en un grupo de archivos SFS, el usuario puede montarlo mediante OPENVM MOUNT /../VMBFS:fileservername:filepoolname /path/to/mount/point. El usuario también debe montar el sistema de archivos raíz, hecho con OPENVM MOUNT /../VMBFS:VMSYS:ROOT/ //, luego se puede iniciar un shell con OPENVM SHELL. A diferencia del SFS normal, el acceso a los sistemas de archivos BFS está controlado por permisos POSIX (con chmod y chown).

A partir de la versión 3 de z/VM, IBM integró OpenEdition en z/VM y le cambió el nombre a OpenExtensions. OpenEdition y OpenExtensions proporcionan compatibilidad con POSIX.2 para CMS. Los programas compilados para ejecutarse bajo el shell de OpenExtensions se almacenan en el mismo formato que los módulos ejecutables CMS estándar. Los editores visuales, como vi, no están disponibles, ya que los terminales 3270 no son compatibles. Los usuarios pueden usar ed o XEDIT en lugar de vi.

Mascota de máquina virtual

A principios de la década de 1980, el grupo VM dentro de SHARE (el grupo de usuarios de IBM) buscó una mascota o un logotipo para que lo adoptara la comunidad. Esto fue en parte una respuesta a los usuarios de MVS de IBM que seleccionaron al pavo como mascota (elegido, según la leyenda, por MVS Performance Group en los primeros días de MVS, cuando su desempeño era un tema delicado). En 1983, el osito de peluche se convirtió en la mascota de facto de VM en SHARE 60, cuando se adhirieron calcomanías de osito de peluche a las etiquetas con los nombres de los "veteranos cariñosos" para marcarlos para los recién llegados como "amigable si se le acerca". Los osos fueron un éxito y pronto aparecieron ampliamente. Se otorgaron osos a miembros de la "Orden de los Caballeros de VM", individuos que hicieron "contribuciones útiles" a la comunidad

Crítica

Si bien VM era relativamente liviano (en comparación con sus contrapartes, como MVS), VM era algo inestable en sus inicios. Se consideraba toda una proeza mantener un sistema VM/370 activo durante más de una semana. Los usuarios también criticaron el sistema de archivos CMS y señalaron que otros sistemas operativos a mediados de la década de 1980 tenían directorios, enlaces simbólicos y otras características clave; CMS no tenía ninguno de estos hasta 1988, cuando salió la versión 6 de VM/SP, que introdujo el sistema de archivos compartidos y alivió estos problemas.

Algunos usuarios también notaron que VM OpenEdition era algo "innecesario."