Máquina virtual (sistema operativo)

VM , a menudo escrito VM/CMS , es una familia de sistemas operativos de máquinas virtuales utilizados en mainframes de IBM , incluidos System/370 , System/390 , IBM Z y sistemas compatibles. Reemplazó al antiguo CP-67 , que constituía la base del sistema operativo CP/CMS . Se lanzó por primera vez como Virtual Machine Facility/370 gratuito para el S/370 en 1972, seguido de actualizaciones de pago ^{[ a ]} y versiones que añadieron compatibilidad con nuevo hardware. ^{[ d ]}

VM crea máquinas virtuales en las que se puede cargar un sistema operativo convencional para permitir la ejecución de programas de usuario. Originalmente, ese sistema operativo era CMS , un sistema sencillo para un solo usuario similar a DOS . VM también se puede usar con otros sistemas operativos de IBM, incluidos sistemas grandes como MVS o VSE , que a menudo se ejecutan de forma independiente sin VM. En otros casos, VM se usa con un sistema operativo más especializado o incluso con programas que proporcionan muchas funciones del sistema operativo. Entre ellos se incluyen RSCS ^{[ e ]} y MUMPS , entre otros.

El núcleo de la arquitectura de la máquina virtual (VM) es el programa de control o hipervisor , abreviado CP, VM-CP y, a veces, de forma ambigua, VM. 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, incluyendo todas las operaciones de E/S y otras operaciones privilegiadas. Realiza el uso compartido de recursos del sistema, incluyendo la administración de dispositivos, la distribución, la administración de almacenamiento virtual y otras tareas tradicionales del sistema operativo. Cada usuario de VM dispone de una máquina virtual independiente con su propio espacio de direcciones , dispositivos virtuales, etc., y que es capaz de ejecutar cualquier software que podría ejecutarse en una máquina independiente (" bare-metal "). Un mainframe de VM determinado suele ejecutar cientos o miles de instancias de máquinas virtuales. VM-CP comenzó su andadura como CP-370, una reimplementación de CP-67 , que a su vez era una reimplementación de CP-40 .

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

• CMS ( Conversational Monitor System , anteriormente conocido como Cambridge Monitor System o CP/CMS ). La mayoría de las máquinas virtuales ejecutan CMS, un sistema operativo ligero para 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. (Si bien una versión anterior de CMS fue descrita, de forma poco halagadora, como " CP/M en un ordenador central", la comparación es un anacronismo; el autor de CP/M, Gary Kildall , era un usuario experimentado de CMS).
• GCS ( Group Control System ) proporciona una simulación limitada de la API de MVS. IBM proporcionó originalmente GCS para ejecutar VTAM sin una máquina virtual de sistema operativo/VS1 de servicio ni la aplicación de red de comunicaciones de VTAM (VCNA). RSCS V2 también se ejecutaba bajo GCS.
• Un sistema operativo convencional. Los sistemas operativos convencionales de IBM (por ejemplo, las familias MVS y DOS/VSE , OS/VS1 , TSS/370 u otra capa del propio VM/370 (véase más abajo)) se pueden cargar y ejecutar sin modificaciones. El hipervisor de VM trata a los sistemas operativos invitados como programas de aplicación con privilegios excepcionales: les impide usar directamente instrucciones privilegiadas (aquellas que permitirían a las aplicaciones tomar el control de todo el sistema o de partes importantes del mismo), pero simula instrucciones privilegiadas en su nombre. La mayoría de los sistemas operativos de mainframe finalizan una aplicación normal que intenta usurpar los privilegios del sistema operativo. El hipervisor de VM puede simular varios tipos de terminales de consola para el sistema operativo invitado, como el 3215 de modo de línea de copia impresa, la familia gráfica 3270 y la consola integrada en las máquinas System/390 e IBM Z más recientes. Otros usuarios pueden acceder a las máquinas virtuales en ejecución mediante el comando DIAL en la pantalla de inicio de sesión, que conectará su terminal al primer dispositivo 3270 emulado disponible, o al primer dispositivo 2703 disponible si el usuario está marcando desde una terminal de máquina de escribir.
• Otra copia de VM. Una instancia de segundo nivel de VM puede virtualizarse completamente dentro de una máquina virtual. Así es como se realiza el desarrollo y las pruebas de VM (una VM de segundo nivel puede potencialmente implementar una virtualización diferente 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 desarrollo de nuevo hardware en IBM. La literatura cita ejemplos prácticos de virtualización de cinco niveles de profundidad . ^{[ 2 ]} Los niveles de VM por debajo del superior también se tratan como aplicaciones, pero con privilegios excepcionales.
• Una copia de la versión para mainframe de AIX o Linux . En el entorno del mainframe, estos sistemas operativos suelen ejecutarse bajo una máquina virtual y se gestionan como cualquier otro sistema operativo invitado. (También pueden ejecutarse como sistemas operativos nativos directamente sobre el hardware). Existieron además las versiones de corta duración IX/370, S/370 y S/390 de AIX (AIX/370 y AIX/ESA).
• Un subsistema de máquina virtual especializado. Varios sistemas ajenos a CMS se ejecutan dentro de máquinas virtuales VM-CP, proporcionando servicios a los usuarios de CMS como la gestión de impresión, la comunicación entre procesos, la compatibilidad con dispositivos especializados y la conexión en red. Estos sistemas operan en segundo plano, ampliando los servicios disponibles para CMS sin modificar el programa de control de VM-CP. Al ejecutarse en máquinas virtuales independientes, reciben las mismas protecciones de seguridad y fiabilidad que otros usuarios de máquinas virtuales. Algunos ejemplos son:
  • RSCS (Subsistema de comunicación y spooling remoto, también conocido como VNET): facilidades de comunicación y transferencia de información entre máquinas virtuales y otros sistemas ^{[ 3 ].}
  • RACF (Instalación de Control de Acceso a Recursos): un sistema de seguridad
  • Sistema de archivos compartidos (SFS), que organiza los archivos compartidos en un árbol de directorios (los servidores suelen denominarse "VMSERVx").
  • VTAM (Método de Acceso a Telecomunicaciones Virtuales): una función que proporciona soporte para una red de arquitectura de red de sistemas.
  • PVM (VM/Pass-Through Facility): una instalación que proporciona acceso remoto a otros sistemas de máquinas virtuales.
  • TCPIP, SMTP, FTPSERVE, PORTMAP, VMNFS: un conjunto de máquinas de servicio que proporcionan conectividad de red TCP/IP a VM/CMS.
  • Db2 Server para VM: un sistema de base de datos SQL; los servidores suelen tener nombres similares a "SQLMACH" y "SQLMSTR".
  • DIRMAINT: un sistema simplificado de gestión de directorios de usuarios (el directorio es una lista de todas las cuentas del sistema, incluyendo la configuración del hardware virtual, las contraseñas de los usuarios y los minidiscos).
  • MUMPS/VM: una implementación de la base de datos y el lenguaje de programación MUMPS que podía ejecutarse como invitado en VM/370. ^{[ 4 ]} MUMPS/VM se introdujo en 1987 y se descontinuó en 1991. ^{[ 5 ]}
• Un sistema operativo escrito o modificado por el usuario, como el CSS de National CSS o el VPS/VM de la Universidad de Boston .

Se conocen las siguientes versiones:

Instalación de máquinas virtuales/370

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

Producto del programa de extensiones del sistema básico VM/370

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

Producto del programa de extensiones del sistema VM/370

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

Producto de máquina virtual/sistema

VM/SP, una versión clave, reemplaza a VM/370, VM/BSE y VM/SE. La versión 1 añadió EXEC2 y el editor de productos del sistema XEDIT ; la versión 3 añadió REXX ; la versión 6 añadió el sistema de archivos compartido. ^{[ 6 ]}

Opción de alto rendimiento para productos de máquinas/sistemas virtuales

VM/SP HPO agrega compatibilidad con dispositivos y funcionalidades adicionales a VM/SP, y permite que ciertas máquinas S/370 que pueden utilizar más de 16 MB de almacenamiento real lo hagan, hasta 64 MB. Esta versión estaba destinada a usuarios que ejecutarían varias máquinas virtuales S/370 simultáneamente. ^{[ 7 ] [ 8 ]}

Ayuda para la migración de máquinas virtuales/arquitectura extendida

VM/XA MA está diseñado para facilitar la migración de MVS/370 a MVS/XA al permitir que ambos se ejecuten simultáneamente en el mismo complejo de procesadores. ^{[ 9 ]}

Instalación del sistema de arquitectura extendida/máquina virtual

VM/XA SF es una versión mejorada de VM/XA MA con funcionalidad y rendimiento optimizados. ^{[ 10 ]}

Producto de sistema de arquitectura extendida/máquina virtual

VM/XA SP es una versión mejorada de VM/XA SF con funcionalidad y rendimiento superiores, ofrecida como reemplazo de VM/SP HPO en máquinas compatibles con S/370-XA. Incluye una versión de CMS que puede ejecutarse en modo S/370 o S/370-XA. ^{[ 11 ]}

Arquitectura de máquinas virtuales/sistemas empresariales

VM/ESA proporciona las funcionalidades de VM/SP, VM/SP HPO y VM/XA SP. La versión 1 de VM/ESA puede ejecutarse en modo S/370, ESA/370 o ESA/390; no admite el modo S/370 XA. La versión 2 solo se ejecuta en modo ESA/390. Las versiones de VM/ESA compatibles con S/370 eran en realidad versiones independientes de las versiones de VM/ESA para ESA/390, ya que las versiones para S/370 se basan en el código fuente más antiguo de VM/SP HPO, y las versiones para ESA/390 se basan en el código fuente más reciente de VM/XA. ^{[ 12 ]}

z/VM

z/VM, la última versión que aún se utiliza ampliamente como una de las principales soluciones de virtualización completa para el mercado de mainframes. z/VM 4.4 fue la última versión que podía ejecutarse en modo ESA/390; las versiones posteriores solo se ejecutan en modo z/Architecture. ^{[ 13 ]}

Las siglas CMS en el nombre hacen referencia al Sistema de Monitorización Conversacional, un componente del producto que es un sistema operativo para un solo usuario que se ejecuta en una máquina virtual y proporciona tiempo compartido conversacional en la máquina virtual.

IBM acuñó el término hipervisor para el 360/65 ^{[ 14 ]} y posteriormente lo utilizó para el controlador DIAG de CP-67.

La instrucción Diagnose ('83'x—sin mnemónico) es una instrucción privilegiada originalmente concebida por IBM para realizar "funciones de diagnóstico integradas u otras funciones dependientes del modelo". ^{[ 15 ]} IBM reutilizó DIAG para "la comunicación entre una máquina virtual y CP". ^{[ 16 ] [ 17 ]} La instrucción contiene dos números de registro de cuatro bits, llamados 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 CP utiliza para determinar qué función DIAGNOSE realizar". ^{[ 16 ]} Las funciones de diagnóstico disponibles incluyen:

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

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

CMS y otros sistemas operativos suelen tener requisitos DASD mucho menores 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 , se debe definir un minidisco en cilindros completos. Un minidisco tiene los mismos atributos que el disco real subyacente, excepto que suele ser más pequeño y el inicio de cada minidisco se asigna al cilindro o bloque 0. Se puede acceder al minidisco ^{[ f ]} utilizando los mismos programas de canal que el disco real.

Un minidisco que ha sido inicializado con un sistema de archivos CMS se denomina minidisco CMS, aunque CMS no es el único sistema que puede utilizarlos.

Es práctica común definir minidiscos de volumen completo para su uso por sistemas operativos invitados como z/OS, en lugar de DEDICATEasignar el volumen a una máquina virtual específica. Los DASD dedicados pueden ofrecer un rendimiento ligeramente superior para los sistemas operativos invitados al eliminar parte de la sobrecarga de CP, pero no se permite el acceso concurrente por parte de otras máquinas virtuales. A menudo se definen enlaces de paquete completo para cada DASD del sistema, que pertenecen al usuario MAINT. Estos enlaces se utilizan para realizar copias de seguridad del sistema mediante el programa de volcado/restauración de DASD (DDR), donde se escribe todo el contenido de un DASD en cinta o en otro DASD.

Con las versiones modernas de máquinas virtuales, la mayor parte del sistema se puede instalar en SFS, quedando solo los minidiscos absolutamente necesarios para que el sistema arranque, y los que pertenecen a las máquinas del servidor de archivos.

La versión 6 de VM/SP introdujo el Sistema de Archivos Compartidos (SFS) ^{[ 18 ]} , que mejoró enormemente las capacidades de almacenamiento de archivos de CMS. El sistema de archivos de minidiscos de CMS no admite directorios (carpetas), a diferencia del SFS. El SFS también ofrece una seguridad más granular. Con los minidiscos de CMS, el sistema se puede configurar para permitir o denegar a los usuarios el acceso de solo lectura o de lectura y escritura a un disco, pero los archivos individuales no pueden tener la misma seguridad. El SFS soluciona este problema y mejora considerablemente el rendimiento.

El SFS es proporcionado por máquinas virtuales de servicio. En un sistema 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 (de usuario). ^{[ 19 ]} Las máquinas servidoras del grupo de archivos poseen varios minidiscos, que generalmente incluyen un disco CMS A (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 número de discos de datos que realmente almacenan archivos de usuario.

Si una cuenta de usuario está configurada para usar solo SFS (y no posee ningún minidisco), el disco A del usuario será FILEPOOL:USERID.y cualquier directorio posterior que el usuario cree será FILEPOOL:USERID.DIR1.DIR2.DIR3donde 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 corrupción del disco (ya que la máquina virtual CMS que realiza las escrituras puede no saber que otra instancia de CMS también está escribiendo en el minidisco).

Las máquinas del servidor de grupos de archivos también dan servicio a un sistema de archivos estrechamente relacionado: el Sistema de Archivos de Bytes (BFS). BFS se utiliza para almacenar archivos en un sistema de archivos de estilo UNIX. Su uso principal es para el entorno POSIX VM OpenExtensions para CMS. Las propias máquinas virtuales de usuario de CMS se comunican con las máquinas virtuales del servidor SFS a través del mecanismo IUCV. ^{[ 20 ]}

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 se lanzó en 1972 como parte del anuncio de las funciones avanzadas del System/370 de IBM (que añadía hardware de memoria virtual y sistemas operativos a la serie System/370 ). Las primeras versiones de VM hasta VM/370 Release 6 continuaron siendo de código abierto hasta 1981, y hoy se consideran de dominio público . Esta política finalizó en 1977 con las actualizaciones de pago VM/SE y VM/BSE, y en 1980 con VM/System Product (VM/SP). Sin embargo, IBM continuó proporcionando actualizaciones en formato de código fuente para el código existente durante muchos años, aunque las actualizaciones para todas las versiones excepto la 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 simulaba el comportamiento de la instrucción privilegiada.

VM siguió siendo una plataforma importante dentro de IBM, utilizada para el desarrollo de sistemas operativos y el uso de tiempo compartido; pero para los clientes seguía siendo el "otro sistema operativo" de IBM. Las familias de sistemas operativos y DOS seguían siendo los productos estratégicos de IBM, y no se animaba a los clientes a usar VM. Quienes lo hicieron establecieron estrechas relaciones de trabajo, continuando el modelo de soporte comunitario de los primeros usuarios de CP/CMS. Mientras tanto, el sistema se enfrentó a luchas internas dentro de IBM sobre qué recursos debían estar disponibles para el proyecto, en comparación con otros proyectos de IBM. Un problema fundamental del sistema se observó a nivel de ventas de IBM: VM/CMS reducía notablemente la cantidad de hardware necesaria para dar soporte a un número determinado de usuarios de tiempo compartido. Después de todo, IBM se dedicaba a la venta de sistemas informáticos.

Melinda Varian ofrece esta fascinante cita, que ilustra el éxito inesperado de VM: ^{[ 21 ]}

Las previsiones de marketing para VM/370 indicaban que no más de un procesador 168 ejecutaría VM durante toda la vida útil del producto. De hecho, el primer 168 entregado a un cliente solo ejecutaba CP y CMS. Diez años después, el diez por ciento de los procesadores de gran capacidad enviados desde Poughkeepsie estarían destinados a ejecutar VM, al igual que una parte muy importante de las máquinas de gama media fabricadas en Endicott. Antes de que transcurrieran quince años, habría más licencias de VM que de MVS.

Una versión de PC DOS que ejecuta CMS en el XT/370 (y posteriormente en el AT/370) se denomina VM/PC. VM/PC 1.1 se basó en la versión 3 de VM/SP. Cuando IBM introdujo las tarjetas de procesador P/370 y P/390, un PC 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 base de VM/SP, IBM también introdujo VM/SP HPO (High Performance Option). Este complemento (que se instala sobre la versión base de VM/SP) mejoró varias funciones clave del sistema, incluyendo la posibilidad de usar más de 16  MB de almacenamiento (RAM) en modelos compatibles (como el 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. Las funciones del sistema de archivos de cola también se mejoraron, permitiendo la creación de 9900 archivos de cola por usuario, en lugar de 9900 para todo el sistema. La arquitectura del sistema de archivos de cola también se optimizó: cada archivo de cola ahora tenía un ID de usuario único asociado, y los bloques de control de archivos de lectura ahora se almacenaban en almacenamiento virtual. El sistema también podía configurarse para denegar el acceso a la función de vector a ciertos usuarios (mediante entradas en el directorio de usuarios). ^{[ 7 ]}

Las versiones de VM desde VM/SP Release 1 admitieron sistemas multiprocesador. Las versiones de System/370 de VM (como VM/SP y VM/SP HPO) admitieron un máximo de dos procesadores, con el sistema operando en modo UP (uniprocesador), modo MP (multiprocesador) o modo AP (procesador conectado). ^{[ 22 ]} El modo AP es igual que el modo MP, excepto que el segundo procesador carece de capacidad de E/S. Las versiones de System/370-XA de VM (como VM/XA) admitieron más. Las versiones de System/390 (como VM/ESA) casi eliminaron el límite por completo, y algunos sistemas z/VM modernos pueden tener hasta 80 procesadores. ^{[ 23 ]} El límite por VM para procesadores definidos es 64.

Cuando IBM presentó la arquitectura extendida System/370 en el procesador 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 gestionaba automáticamente algunas instrucciones privilegiadas y volvía a CP en los casos que no podía gestionar. El gestor de recursos del procesador/sistema (PR/SM) del posterior procesador 3090 también utilizaba SIE. Existieron varios productos VM/XA antes de que finalmente fuera reemplazado por VM/ESA y z/VM.

Además de la red RSCS , IBM también proporcionó a los usuarios la red VTAM . ACF/VTAM para VM era totalmente compatible con ACF/VTAM en MVS y VSE. ^{[ 24 ]} Al igual que RSCS, VTAM en VM se ejecutaba bajo el sistema operativo especializado GCS. Sin embargo, VM también admitía redes TCP/IP. A finales de la década de 1980, IBM produjo una pila TCP/IP para VM/SP y VM/XA. ^{[ 25 ]} La pila admitía redes IPv4 y una variedad de sistemas de interfaz de red (como enlaces de canal a canal entre mainframes o un PC IBM RT especializado que retransmitía el tráfico a una red Token Ring o Ethernet ). La pila proporcionaba soporte para conexiones Telnet , ya sea desde emuladores de terminal simples en modo de línea o emuladores compatibles con VT100, o emuladores de terminal IBM 3270 adecuados. La pila también proporcionaba 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. ^{[ 26 ]}

También existía una cuarta opción de red, conocida como VM/Pass-Through Facility (o más comúnmente llamada, PVM). PVM, al igual que VTAM, permitía conexiones a sistemas VM/CMS remotos, así como a otros sistemas IBM. ^{[ 27 ]} Si dos nodos VM/CMS estaban conectados entre sí 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 arrendada), un usuario podía conectarse remotamente a cualquiera de los sistemas ingresando "DIAL PVM" en la pantalla de inicio de sesión de VM, luego ingresando el nombre del nodo del sistema (o seleccionándolo de una lista de nodos disponibles). Alternativamente, un usuario que ejecutaba CMS podía usar el programa PASSTHRU que se instalaba junto con PVM, lo que permitía un acceso rápido a sistemas remotos sin tener que cerrar la sesión del usuario. PVM también admitía el acceso a sistemas que no eran VM, utilizando una técnica de emulación 3x74. Las versiones posteriores de PVM también incluían 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 proporcionaba una red sencilla, fácil de implementar y relativamente fiable. Los sitios VM se interconectaban mediante una máquina virtual RSCS en cada sistema 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. El comando "NOTE" utilizaba XEDIT para mostrar un cuadro de diálogo para crear un correo electrónico, desde el cual el usuario podía enviarlo. Si el usuario especificaba una dirección con el formato user at node, el archivo de correo electrónico se entregaba a RSCS, que a su vez lo entregaba al usuario de destino en el sistema de destino. Si el sitio tenía TCP/IP instalado, RSCS podía trabajar con la máquina del servicio SMTP para enviar notas (correos electrónicos) a sistemas remotos, así como para recibirlas. Si el usuario especificaba user at some.host.name, el programa NOTE entregaba el correo electrónico a la máquina del servicio SMTP, que a su vez lo enrutaba al sitio de destino en Internet.

El rol de VM cambió dentro de IBM cuando la evolución del hardware conllevó cambios significativos en la arquitectura del procesador. La retrocompatibilidad siguió siendo una piedra angular de la familia de mainframes 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 la serie z de 64 bits hizo que el enfoque de VM fuera mucho más atractivo. VM también se utilizó en centros de datos que migraron de DOS/VSE a MVS y es útil al ejecutar mainframe AIX y Linux , plataformas que se volverían cada vez más importantes. La plataforma z/VM actual finalmente ha logrado el reconocimiento dentro de IBM que los usuarios de VM sentían que merecía desde hace tiempo. Algunos sitios z/VM ejecutan miles de usuarios de máquinas virtuales simultáneas en un solo sistema. z/VM se lanzó por primera vez en octubre de 2000 ^{[ 28 ]} y continúa en uso y desarrollo activos.

IBM y terceros han ofrecido numerosas aplicaciones y herramientas que se ejecutan en máquinas virtuales. Algunos ejemplos son RAMIS , FOCUS , SPSS , NOMAD , DB2 , REXX , RACF y OfficeVision . La oferta actual de máquinas virtuales abarca una amplia gama de aplicaciones para mainframes, incluyendo servidores HTTP , gestores de bases de datos, herramientas de análisis, paquetes de ingeniería y sistemas financieros.

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úscula del comando son opcionales ^{[ 29 ].}

A partir de VM/ESA Versión 2, IBM introdujo la característica opcional de pago OpenEdition para VM/ESA Shell and Utilities Feature , ^{[ 30 ]} que proporciona compatibilidad POSIX para CMS. La característica más destacada 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 estándar de VM tienen soporte para archivos y rutas 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 montarla usando OPENVM MOUNT /../VMBFS:fileservername:filepoolname /path/to/mount/point. El usuario también debe montar el sistema de archivos raíz, lo que se hace 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 ^{[ 13 ]} y lo renombró como OpenExtensions. OpenEdition y OpenExtensions proporcionan compatibilidad con POSIX.2 a CMS. ^{[ 31 ]} Los programas compilados para ejecutarse bajo el entorno de OpenExtensions se almacenan en el mismo formato que los módulos ejecutables estándar de CMS. 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.

A principios de la década de 1980, el grupo VM dentro de SHARE (el grupo de usuarios de IBM) buscó una mascota o logotipo para que la comunidad lo adoptara. Esto fue en parte una respuesta a que los usuarios de MVS de IBM eligieran el pavo como mascota (elegido, según la leyenda, por el Grupo de Rendimiento de MVS en los primeros días de MVS, cuando su rendimiento era un tema delicado). En 1983, el oso de peluche se convirtió en la mascota de facto de VM en SHARE 60, cuando se colocaron pegatinas de osos de peluche en las etiquetas de identificación de los "veteranos más cariñosos" para indicar a los recién llegados que eran "amigables si se les acercaban". Los osos fueron un éxito y pronto aparecieron por todas partes. ^{[ 32 ]} Se otorgaron osos a los miembros de la "Orden de los Caballeros de VM", personas que hicieron "contribuciones útiles" a la comunidad. ^{[ 33 ] [ 34 ]}

• History of CP/CMS
• Time-sharing system evolution

Primary CP/CMS sources

Fuentes adicionales de CP/CMS

Antecedentes de fuentes de CP/CMS

Recursos adicionales en línea para CP/CMS

• Bob DuCharme, Manual de sistemas operativos, Parte 5: VM/CMS : una guía de usuario bastante detallada para VM/CMS
• EC Hendricks y TC Hartmann, "Evolución de un subsistema de máquina virtual", IBM Systems Journal Vol. 18, pp. 111–142 (1979): Diseño e implementación de RSCS
• IBM Corporation, Introducción a IBM Virtual Machine Facility/370 , GC20-1800, (1972): el manual original
• Publicación de IBM Redbooks – Libro de texto de z/VM
• IBM: Portal z/VM
• IBM: Manuales de z/VM
• Documentación de máquinas virtuales/PC sobre Bitsavers