Sistema de máquina virtual

La versión actual de la página aún no ha sido revisada por colaboradores experimentados y puede diferir significativamente de la versión revisada el 14 de febrero de 2021; la verificación requiere 1 edición .
MVS
Desarrollador IBM , NIIEVM
familia de sistemas operativos máquina virtual
tipo de núcleo Máquina virtual
Licencia Propiedad
Estado histórico

El sistema de máquina virtual ( SVM ) es un sistema operativo para la computadora de la UE , un análogo del sistema IBM VM .

Características principales de SVM

VM (VM, y su versión anterior CP/CMS) es el primer sistema en el que se implementó la tecnología de máquina virtual . La virtualización en CBM era consistente y completa, en particular, una máquina virtual podía ejecutar otra copia del sistema CBM, y así sucesivamente. Además, ejecutar CBM en una máquina virtual de CBM fue el método recomendado para generar una nueva versión del sistema para su instalación. En particular, esto significaba que cualquier dispositivo informático real podía representarse mediante un método u otro como un dispositivo virtual en una máquina virtual. Hasta el momento, ninguna otra implementación de máquinas virtuales tiene esta propiedad.

Estado de CBM

El sistema de máquinas virtuales en el campo socialista primero fue adaptado en la versión 1 por la empresa Robotron (GDR), y luego, a partir de la versión 2, desarrollado por NIIEVM (Minsk). Gracias a la actividad de NIIEVM, el SVM se consideró en la URSS como uno de los componentes principales del software del sistema informático ES y, posteriormente, se convirtió en la base de la versión 7 del sistema operativo ES , que se ofreció como una opción estándar para su uso en ES. sistemas informáticos Ryad-3 y superiores. Las más extendidas en la URSS fueron las versiones de SVM 3 y 4. La versión 5 ya se lanzó durante el colapso de la URSS y el abandono masivo del uso de equipos informáticos ES y, por lo tanto, no se usó ampliamente y bajo el nombre de "SVM". versión 6 "Los especialistas de Minsk lanzaron un paquete de programas para VM, brindando su máxima compatibilidad con las aplicaciones de VM.

Por otro lado, por razones que no tienen una explicación racional, IBM nunca ha fomentado el uso de su sistema operativo VM, y el marketing de IBM siempre ha posicionado a la VM en un papel secundario en relación con otros sistemas operativos mainframe: MVS, OS e incluso DOS, mucho menos tecnológicamente avanzado y fácil de usar. Lo más probable es que el bajo presupuesto para el desarrollo de la VM como proyecto experimental inicial no permitió que la dirección financiera de IBM la reconociera como igual a aquellos sistemas en los que se gastó mucho más dinero.

Arquitectura SVM

Arquitectónicamente, el SVM constaba de varios componentes independientes. El componente central era el monitor de máquina virtual (VMM, el nombre de IBM es CP, Control Program), que controlaba el hardware de una computadora real e implementaba un conjunto de máquinas virtuales con una configuración dada. Los componentes restantes eran sistemas operativos o programas independientes del sistema de máquinas virtuales que se ejecutaban bajo el control del MVM: el subsistema de procesamiento de diálogo (PDO), el subsistema de transferencia de archivos de red (NFT), el subsistema de conmutación lógica (PLC) de la estación de suscriptor, el subsistema de análisis de volcado (PAD), transferencia de archivos del subsistema de control remoto (PDP), subsistema de control de hardware (PKT), herramientas de generación y mantenimiento (SSS).

DOP

PDO (Subsistema de procesamiento conversacional, nombre de IBM - CMS , Conversational Monitor System, anteriormente Cambridge Monitor System; traducción inversa al inglés - PTS, Programación y sistema de prueba) era el sistema operativo principal de la máquina virtual en el CBM, en el que trabajaban los usuarios. PDO proporcionó al usuario una interfaz de diálogo; de hecho, el trabajo del usuario en la terminal en PDO en una máquina virtual se parecía al trabajo en una computadora personal. Este fue un paso adelante muy serio en comparación con los sistemas operativos anteriores de las computadoras ES, cuyas capacidades de diálogo estaban completamente ausentes o eran muy limitadas.

Subsistemas de servicio

Los subsistemas PSP, PLC, PAD, PDP, PKT, SGO estaban destinados a tareas de mantenimiento del sistema y no eran utilizados por los programadores y usuarios de la aplicación.

Sistema operativo invitado

Además, en la máquina virtual CBM era posible ejecutar cualquier sistema operativo de computadora ES diseñado para ejecutarse en hardware real (el llamado sistema operativo invitado): ES OS, ES DOS, ES MOS, MVS, etc. Como parte del ES OS versión 7, se desarrolló un sistema operativo BOS especial que es funcionalmente equivalente a la versión 6 (SVS) de la UE, pero diseñado específicamente para ejecutarse en la máquina virtual SVM. BOS, a diferencia de la gran mayoría de otras herramientas de sistemas informáticos ES, fue un desarrollo independiente de programadores soviéticos, independiente de IBM. Dado que el sistema operativo de la UE era un sistema por lotes, los usuarios de PDO podían transferirle paquetes de tareas preparados y obtener resultados utilizando un perforador virtual y un ADCP virtual .

Rendimiento del monitor de máquina virtual

En teoría, Virtual Machine Monitor era capaz de admitir hasta 10 000 máquinas virtuales en un solo sistema real. En la práctica, el número de máquinas virtuales activas simultáneamente estaba limitado por el rendimiento de la computadora y podía llegar a varias decenas.

En las computadoras EC Ryad-3 y superiores, se implementaron los medios de soporte de microprogramas para SVM.

Seguimiento del tiempo

La arquitectura de SVM hizo posible organizar de forma natural la contabilidad del uso del tiempo de la computadora, lo cual era muy importante para los sistemas multiusuario que eran costosos de operar. El comando MVM QUERY T  IME , disponible para el usuario de la máquina virtual, permitió conocer la fecha y hora actual, así como la cantidad total de tiempo de procesador de los procesadores reales y virtuales utilizados en la sesión actual de la maquina virtual Se popularizó un sencillo script en lenguaje REXX , que al salir del sistema emitía dicho comando, multiplicaba el resultado obtenido por el costo del tiempo de máquina del sistema e informaba al usuario el monto total que su trabajo costó para la organización operativa. el ordenador. Para un programador que no ocupó el procesador con cálculos intensivos, sino que realizó el desarrollo y la depuración habituales de los programas, en el EU-1066 el costo típico del tiempo de la máquina fue de aproximadamente 10 rublos por día laboral (es decir, fue aproximadamente igual a salarios). Los programas intensivos en recursos durante la operación podrían usar órdenes de magnitud más tiempo de procesador. Por supuesto, los programadores en la URSS no pagaron el tiempo de la máquina de su propio bolsillo, pero esta cifra muestra que el trabajo de los programadores en la optimización de código dio sus frutos muy rápidamente en ese momento.

Compatible con el sistema operativo de la UE

Además de la posibilidad de utilizar EU OS y BOS bajo el control de MVM, el propio PDO se diseñó de forma que facilitara al máximo la transferencia de programas desde EU OS. Era posible conectar discos en formato EU OS a la máquina virtual PDO e iniciar directamente los módulos de arranque del EU OS con un comando OSRUN especial (con ciertas restricciones en las llamadas al sistema utilizadas). Además, la mayoría de las aplicaciones para el sistema operativo de la UE podrían simplemente volver a compilarse bajo PDO para obtener ejecutables de PDO reales. Las llamadas al sistema PDO eran máximamente compatibles con el sistema operativo de la UE, la mayoría de los programas de aplicación para las computadoras de la UE estaban escritos en su subconjunto común y podían ejecutarse tanto en el entorno del sistema operativo de la UE (y MCS) como en el entorno PDO.

Segmentos compartidos

Para asegurar el uso eficiente del sistema de memoria virtual, se previó destinar una parte del espacio de direcciones, a petición del programador del sistema, para los denominados segmentos compartidos. Por ejemplo, un editor de texto, compilador o biblioteca de soporte de lenguaje de programación podría cargarse en un segmento compartido y, por lo tanto, todos los usuarios que los usen accederían efectivamente a la misma copia en la memoria virtual, en lugar de crear una copia separada para cada máquina virtual.

Trabajando con archivos en PDO

A diferencia de DOS ES, OS ES y MVS, que proporcionaban un sistema de gestión de archivos muy engorroso e inconveniente para el uso diario (más precisamente, en su terminología, conjuntos de datos), PDO implementó el concepto de los llamados minidiscos con la capacidad de usar su propio sistema de archivos. El minidisco era un dispositivo de disco virtual emulado por un VMM. El minidisco podría formatearse en el sistema de archivos PDO, en cuyo caso contenía un solo directorio de archivos. El ID de archivo constaba del nombre de archivo (hasta 8 caracteres), la extensión (hasta 8 caracteres) y el modo de archivo (1 letra de unidad y 1 dígito de modo de acceso). Los componentes del nombre estaban separados por un espacio, el modo de archivo podía omitirse por completo o solo podía especificarse la letra de la unidad. Por ejemplo, un archivo llamado PROFILE EXEC A1  es un archivo de inicio del sistema PDO del tipo EXEC (en uno de los lenguajes de scripting) en el minidisco principal del usuario A , con el modo de acceso habitual 1 .

La estructura de los archivos PDO se correspondía con la estructura de los conjuntos de datos de EU OS (con la excepción de los tipos de conjuntos de datos más complejos), es decir, cada archivo se dividía en registros de un determinado formato y longitud. El principal formato de archivo de texto en PDO era el formato F(80) , es decir, la imagen de una baraja virtual de cartas perforadas de 80 columnas .

Los minidiscos se podían compartir entre varias máquinas virtuales, por lo que los minidiscos se compartían con los programas del sistema y los usuarios tenían acceso a los datos de los demás. Proporcionó protección con contraseña para minidiscos para lectura y escritura.

Para ser compatible con EU DOS, EU OS y MBC, el PDO utilizó principalmente el mecanismo de asociación de archivos externos prestado de estos sistemas. Aunque un programa en PDO podía abrir un archivo en un disco directamente por su nombre, de hecho, solo unos pocos programas del sistema, como las utilidades de archivo, un editor de texto, etc., estaban organizados de esta manera. El mecanismo estándar para los programas de aplicación era asociar un archivo en un disco (o dispositivo) con un nombre de archivo en el programa usando el comando FI LEDEF emitido antes de que se ejecute el programa (un análogo de la declaración DD en el lenguaje JCL para DOS, OS y MBC). Por ejemplo, el comando FI LEDEF SYSPRINT  DISK  TEST LISTING significaba que la salida del sistema ( SYSPRINT ) de los siguientes programas debería escribirse en un archivo en el minidisco PDO con el nombre TEST LISTING (y el modo implícito A1 ).

Truncamientos y abreviaturas

Se permitió el uso de truncamientos y abreviaturas en la mayoría de los comandos de programas VMM, PDO y del sistema, así como en algunos operandos de comando, para la conveniencia del trabajo interactivo en el CBM. Por ejemplo, la palabra READER podría ingresarse como una de las abreviaturas READER , READE , READ , REA , RE , R , o como la abreviatura RDR . Los comandos y operandos de uso más frecuente tenían truncamientos más cortos, hasta una letra, los que se usaban con menos frecuencia tenían otros más largos. En la descripción de la sintaxis, la parte obligatoria del truncamiento estaba en mayúscula o subrayada, por ejemplo  :  LECTOR | RDR .

Editor XEDIT

A partir de la versión 3 de CBM, PDO utilizó un editor de texto X EDIT muy avanzado que, en particular, estaba completamente controlado por el lenguaje REXX. Con la ayuda de los scripts REXX para XEDIT, se implementaron muchos sistemas complejos, como, por ejemplo, sistemas para el control colectivo de versiones de programas. Posteriormente, se implementaron clones de XEDIT (KEDIT, SEDIT, THE) en varios sistemas operativos de computadoras personales, pero en realidad no arraigaron, ya que la ideología de XEDIT se centró en gran medida en las características de los terminales de computadora central. THE (The Hessling Editor) se distribuye actualmente bajo licencia GPL para plataformas Unix , z/OS , MS-DOS , OS/2 , Windows , QNX , Amiga , BeOS , Mac OS X. Curiosamente, la versión z/OS de THE la distribuye la propia IBM.

Correo electrónico

Como parte del PDO, se suministraron programas para trabajar con correo electrónico. Por lo general, el correo electrónico funcionaba entre usuarios de una computadora real (para modelos más antiguos de computadoras EC, esto podría ser cientos de usuarios en terminales dentro de un radio de varios kilómetros), pero usando las telecomunicaciones, que todavía eran una curiosidad en esos días, varios las máquinas podrían conectarse en red. También se implementó un sistema de transmisión instantánea de mensajes cortos entre usuarios.

Los sistemas de programación y el lenguaje REXX

Las principales herramientas de programación para PDO fueron los lenguajes de programación REXX y anteriores EXEC y EXEC2 , ensambladores , compiladores de PL/1 , Fortran , Cobol . Asimismo, se han implementado muchos otros sistemas de programación para PDO, tales como: Pascal , C , Lisp , Prolog , sistema de computación simbólica REDUCE , lenguaje tecnológico para desarrollar software de sistema PLS (lenguaje de programación) , etc.

El intérprete de lenguaje REXX se incluyó por primera vez en el PDO en la versión 3 de CBM. Posteriormente, el lenguaje REXX se generalizó en el sistema operativo OS/2 y también se implementó para muchos otros sistemas operativos. En CVM, la popularidad de REXX entre los usuarios era más limitada que en OS/2, ya que el lenguaje de secuencias de comandos de las versiones anteriores de PDO, EXEC2, brindaba oportunidades bastante amplias, y la necesidad de utilizar el lenguaje REXX más complejo surgía con menos frecuencia, mientras que en OS/2, la única alternativa a REXX era el lenguaje de archivo extremadamente limitado .bat /.cmd.

Literatura