MVS

Almacenamiento virtual múltiple, más comúnmente llamado MVS, era el sistema operativo más utilizado en las computadoras centrales IBM System/370 y System/390. IBM desarrolló MVS, junto con OS/VS1 y SVS, como sucesor de OS/360. No está relacionado con otras líneas de sistemas operativos de mainframe de IBM, por ejemplo, VSE, VM, TPF.

Resumen

Lanzado por primera vez en 1974, MVS se amplió con productos de programa con nuevos nombres varias veces:

• primera a MVS/SE (MVS/System Extensiones),
• junto a MVS/SP (MVS/System Product) Versión 1,
• junto a MVS/XA (MVS/eXtended Architecture),
• junto a MVS/ESA (MVS/Enterprise Systems Architecture),
• entonces a OS/390 y
• Finalmente a z/OS (cuando se agregó soporte de 64 bits con los modelos zSeries). IBM agregó soporte UNIX (originalmente llamado OpenEdition MVS) en MVS/SP V4.3 y ha obtenido certificaciones POSIX y UNIXTM a varios niveles diferentes de IEEE, X/Open y The Open Group. El núcleo de MVS sigue siendo fundamentalmente el mismo sistema operativo. Por diseño, programas escritos para MVS funcionan en z/OS sin modificaciones.

Al principio, IBM describió MVS simplemente como una nueva versión de OS/VS2, pero, de hecho, fue una reescritura importante. La versión 1 de OS/VS2 fue una actualización de OS/360 MVT que retuvo la mayor parte del código original y, al igual que MVT, se escribió principalmente en lenguaje ensamblador. El núcleo de MVS se escribió casi en su totalidad en Assembler XF, aunque algunos módulos se escribieron en PL/S, pero no los sensibles al rendimiento, en particular, el supervisor de entrada/salida (IOS). El uso de IBM de "OS/VS2" enfatizó la compatibilidad hacia arriba: los programas de aplicación que se ejecutaban bajo MVT ni siquiera necesitaban recompilarse para ejecutarse bajo MVS. Los mismos archivos de lenguaje de control de trabajos podrían usarse sin cambios; Los servicios públicos y otras instalaciones secundarias como TSO funcionaron sin cambios. IBM y los usuarios llamaron casi unánimemente al nuevo sistema MVS desde el principio, e IBM continuó usando el término MVS en el nombre de versiones posteriores principales como MVS/XA.

Evolución de MVS

OS/360 MFT (Multiprogramación con un número fijo de tareas) proporcionó multitarea: varias particiones de memoria, cada una de un tamaño fijo, se configuraron cuando se instaló el sistema operativo y cuando el operador las redefinió. Por ejemplo, podría haber una partición pequeña, dos particiones medianas y una partición grande. Si hubiera dos programas grandes listos para ejecutarse, uno tendría que esperar hasta que el otro terminara y desocupara la partición grande.

OS/360 MVT (multiprogramación con un número variable de tareas) fue una mejora que perfeccionó aún más el uso de la memoria. En lugar de utilizar particiones de memoria de tamaño fijo, MVT asignó memoria a regiones para los pasos de trabajo según fuera necesario, siempre que hubiera suficiente memoria física contigua disponible. Este fue un avance significativo sobre la gestión de memoria de MFT, pero tenía algunas debilidades: si un trabajo asignaba memoria dinámicamente (como lo hacen la mayoría de los programas de clasificación y los sistemas de gestión de bases de datos), los programadores tenían que estimar la memoria máxima del trabajo. requisito y predefinirlo para MVT. Un paso de trabajo que contenía una combinación de programas pequeños y grandes desperdiciaba memoria mientras se ejecutaban los programas pequeños. Lo que es más grave, la memoria podría fragmentarse, es decir, la memoria no utilizada por los trabajos actuales podría dividirse en fragmentos inútilmente pequeños entre las áreas utilizadas por los trabajos actuales, y el único remedio era esperar hasta que terminaran algunos trabajos actuales antes de iniciar otros nuevos.

A principios de la década de 1970, IBM trató de mitigar estas dificultades mediante la introducción de la memoria virtual (que IBM denominó "almacenamiento virtual"), que permitía a los programas solicitar espacios de direcciones más grandes que la memoria física. Las implementaciones originales tenían un solo espacio de direcciones virtuales, compartido por todos los trabajos. OS/VS1 era OS/360 MFT dentro de un solo espacio de direcciones virtuales; OS/VS2 SVS era OS/360 MVT dentro de un solo espacio de direcciones virtuales. Entonces OS/VS1 y SVS en principio tenían las mismas desventajas que MFT y MVT, pero los impactos eran menos severos porque los trabajos y los operadores podían solicitar particiones mucho más grandes con una granularidad de 2 KiB (para OS/VS1) o regiones con una granularidad de 4 KiB. (para SVS), y las solicitudes procedían de un espacio de direcciones de 16 MiB, incluso si el almacenamiento físico era más pequeño. Al igual que en OS/360 MVT, los usuarios de TSO en SVS se asignaban a una región de TSO durante el procesamiento de inicio de sesión y competían con otros usuarios asignados a la misma región, esencialmente con la misma lógica de intercambio que TSO en MVT.

A mediados de la década de 1970, IBM presentó MVS, que no solo admitía un almacenamiento virtual mayor que el almacenamiento real disponible, al igual que SVS, sino que también permitía ejecutar un número indefinido de aplicaciones en diferentes espacios de direcciones. Dos programas simultáneos podrían intentar acceder a la misma dirección de memoria virtual, pero el sistema de memoria virtual redirigió estas solicitudes a diferentes áreas de la memoria física. Cada uno de estos espacios de direcciones constaba de tres áreas: un sistema operativo (una instancia compartida por todos los trabajos), un área de aplicación única para cada aplicación y un área virtual compartida utilizada para diversos fines, incluida la comunicación entre trabajos. IBM prometió que las áreas de aplicación siempre tendrían al menos 8 MB. Esto convirtió a MVS en la solución perfecta para los problemas comerciales que surgieron de la necesidad de ejecutar más aplicaciones.

MVS maximizó el potencial de procesamiento al proporcionar capacidades de multiprogramación y multiprocesamiento. Al igual que sus predecesores MVT y OS/VS2 SVS, MVS admitía la multiprogramación; las instrucciones del programa y los datos asociados son programados por un programa de control y ciclos de procesamiento dados. A diferencia de un sistema operativo de programación única, estos sistemas maximizan el uso del potencial de procesamiento al dividir los ciclos de procesamiento entre las instrucciones asociadas con varios programas diferentes que se ejecutan simultáneamente. De esta forma, el programa de control no tiene que esperar a que se complete la operación de E/S antes de continuar. Al ejecutar las instrucciones para múltiples programas, la computadora puede alternar entre programas activos e inactivos.

Las primeras ediciones de MVS (mediados de la década de 1970) estuvieron entre las primeras de la serie IBM OS en admitir configuraciones multiprocesador, aunque la variante M65MP de OS/360 que se ejecuta en 360 Models 65 y 67 había brindado compatibilidad limitada con multiprocesador. El 360 Model 67 también había alojado los sistemas operativos TSS/360, MTS y CP-67 con capacidad multiprocesador. Debido a que los sistemas de procesamiento múltiple pueden ejecutar instrucciones simultáneamente, ofrecen una mayor potencia de procesamiento que el sistema de procesamiento único. Como resultado, MVS pudo abordar los problemas comerciales provocados por la necesidad de procesar grandes cantidades de datos.

Los sistemas de multiprocesamiento están poco acoplados, lo que significa que cada computadora tiene acceso a una carga de trabajo común, o estrechamente acoplados, lo que significa que las computadoras comparten el mismo almacenamiento real y están controlados por una sola copia del sistema operativo. MVS retuvo tanto el multiprocesamiento débilmente acoplado del procesador de soporte adjunto (ASP) como el multiprocesamiento estrechamente acoplado de OS/360 Model 65 Multiprocessing. En sistemas estrechamente acoplados, dos CPU compartían acceso simultáneo a la misma memoria (y copia del sistema operativo) y periféricos, proporcionando una mayor potencia de procesamiento y un grado de degradación elegante si fallaba una CPU. En configuraciones débilmente acopladas, cada uno de un grupo de procesadores (único y/o estrechamente acoplado) tenía su propia memoria y sistema operativo, pero los periféricos compartidos y el componente del sistema operativo JES3 permitían administrar todo el grupo desde una consola. Esto proporcionó una mayor resiliencia y permitió a los operadores decidir qué procesador debería ejecutar qué trabajos desde una cola de trabajos central. MVS JES3 brindó a los usuarios la oportunidad de conectar en red dos o más sistemas de procesamiento de datos a través de discos compartidos y adaptadores de canal a canal (CTCA's). Esta capacidad finalmente estuvo disponible para los usuarios de JES2 como SPOOL de acceso múltiple (MAS).

MVS originalmente admitía direccionamiento de 24 bits (es decir, hasta 16 MB). A medida que el hardware subyacente progresó, admitió direccionamiento de 31 bits (XA y ESA; hasta 2048 MB) y ahora (como z/OS) de 64 bits. Los motivos más significativos para la rápida actualización al direccionamiento de 31 bits fueron el crecimiento de grandes redes de procesamiento de transacciones, en su mayoría controladas por CICS, que se ejecutaban en un solo espacio de direcciones, y el sistema de gestión de bases de datos relacionales DB2 necesitaba más de 8 MB de aplicación. espacio de direcciones para ejecutarse de manera eficiente. (Las primeras versiones se configuraron en dos espacios de direcciones que se comunicaban a través del área virtual compartida, pero esto imponía una sobrecarga significativa ya que todas esas comunicaciones se transmitían a través del sistema operativo).

Las principales interfaces de usuario de MVS son: el lenguaje de control de trabajos (JCL), que se diseñó originalmente para el procesamiento por lotes, pero a partir de la década de 1970 también se usó para iniciar y asignar recursos a trabajos interactivos de larga ejecución como CICS; y TSO (Opción de tiempo compartido), la interfaz interactiva de tiempo compartido, que se utilizaba principalmente para ejecutar herramientas de desarrollo y algunos sistemas de información para usuarios finales. ISPF es una aplicación de TSO para usuarios en terminales de la familia 3270 (y más tarde, también en VM), que permite al usuario realizar las mismas tareas que la línea de comandos de TSO pero en una forma orientada a menús y formularios, y con un editor de pantalla completa y un explorador de archivos. La interfaz básica de TSO es la línea de comandos, aunque posteriormente se agregaron funciones para las interfaces basadas en formularios.

MVS dio un gran paso adelante en la tolerancia a fallos, basado en la función STAE anterior, que IBM llamó recuperación de software. IBM decidió hacer esto después de años de experiencia práctica en el mundo real con MVT en el mundo empresarial. Las fallas del sistema ahora estaban teniendo un gran impacto en los negocios de los clientes, e IBM decidió dar un gran salto en el diseño, para asumir que a pesar de las mejores técnicas de desarrollo y prueba de software, 'se producirán problemas'. Esta suposición profunda fue fundamental para agregar grandes porcentajes de código de tolerancia a fallas al sistema y probablemente contribuyó al éxito del sistema en tolerar fallas de software y hardware. Es difícil obtener información estadística para demostrar el valor de estas características de diseño (¿cómo se pueden medir los problemas 'prevenidos' o 'recuperados'?), pero IBM, en muchas dimensiones, ha mejorado estas características de recuperación de software tolerante a fallas y resolución rápida de problemas, a lo largo del tiempo.

Este diseño especificó una jerarquía de programas de manejo de errores, en modo de sistema (núcleo/'privilegiado'), denominadas rutinas de recuperación funcional, y en modo de usuario ('tarea' o &# 39;programa de problemas'), llamado "ESTAE" (Rutinas extendidas de salida anormal de tarea especificada) que se invocaron en caso de que el sistema detectara un error (procesador de hardware o error de almacenamiento, o error de software). Cada rutina de recuperación hizo que la 'línea principal' función reinvocable, datos de diagnóstico de errores capturados suficientes para depurar el problema que causa, y 'reintentado' (reinvocar la línea principal) o 'filtrado' (proceso de error escalado a la siguiente rutina de recuperación en la jerarquía).

Por lo tanto, con cada error, el sistema capturaba datos de diagnóstico e intentaba realizar una reparación y mantener el sistema en funcionamiento. Lo peor posible era eliminar un espacio de direcciones de usuario (un 'trabajo') en el caso de errores no reparados. Aunque fue un punto de diseño inicial, no fue sino hasta la versión más reciente de MVS (z/OS), que no solo se garantizó que el programa de recuperación tuviera su propia rutina de recuperación, sino que cada rutina de recuperación ahora tiene su propia rutina de recuperación. Esta estructura de recuperación se incorporó en el programa de control básico de MVS, y las funciones de programación están disponibles y son utilizadas por desarrolladores de programas de aplicaciones y desarrolladores de terceros.

Prácticamente, la recuperación del software MVS facilitó y dificultó la depuración de problemas. La recuperación de software requiere que los programas dejen 'pistas' de dónde están y qué están haciendo, lo que facilita la depuración, pero el hecho de que el procesamiento progrese a pesar de un error puede sobrescribir las pistas. La captura temprana de datos en el momento del error maximiza la depuración y existen instalaciones para las rutinas de recuperación (modo de tarea y sistema, ambos) para hacer esto.

IBM incluyó criterios adicionales para un problema de software importante que requería el servicio de IBM. Si un componente de la línea principal no pudo iniciar la recuperación del software, se consideró una falla notificable válida. Además, si una rutina de recuperación no pudo recopilar datos de diagnóstico significativos de modo que el problema original pudiera resolverse con los datos recopilados por esa rutina de recuperación, los estándares de IBM dictaban que esta falla era notificable y requería reparación. Por lo tanto, los estándares de IBM, cuando se aplican rigurosamente, fomentan la mejora continua.

IBM continuó brindando soporte a la principal herramienta de capacidad de servicio Dynamic Support System (DSS) que había introducido en OS/VS1 y OS/VS2 versión 1. Esta función interactiva podría invocarse para iniciar una sesión para crear procedimientos de diagnóstico, o invocarse ya -procedimientos almacenados. Los procedimientos capturaron eventos especiales, como la carga de un programa, la E/S de un dispositivo, las llamadas a procedimientos del sistema y luego desencadenaron la activación de los procedimientos definidos previamente. Estos procedimientos, que podían invocarse recursivamente, permitían la lectura y escritura de datos y la alteración del flujo de instrucciones. Se utilizó hardware de grabación de eventos de programa.

IBM eliminó el soporte para DSS con la Unidad seleccionable 7 (SU7), una actualización de OS/VS2 versión 3.7 requerida por el producto del programa OS/VS2 MVS/System Extensions (MVS/SE), número de programa 5740-XEl. El grupo de usuarios SHARE aprobó el requisito de que IBM restableciera DSS, e IBM proporcionó un PTF para permitir el uso de DSS después de instalar MVS/SE.

IBM volvió a dejar de admitir DSS con SU64, una actualización de OS/VS2 versión 3.8 requerida por la versión 2 de MVS/SE.

La explotación de la grabación de eventos de programa (PER) se realizó mediante la mejora del comando SLIP de diagnóstico con la introducción del soporte PER (SLIP/Per) en SU 64/65 (1978).

Múltiples copias de MVS (u otros sistemas operativos de IBM) podrían compartir el misma máquina si esa máquina estaba controlada por VM/370. En este caso, VM/370 era el sistema operativo real y se consideraba el sistema "invitado" sistemas operativos como aplicaciones con privilegios inusualmente altos. Como resultado de mejoras de hardware posteriores, una instancia de un sistema operativo (ya sea MVS, VM con invitados u otro) también podría ocupar una partición lógica (LPAR) en lugar de un sistema físico completo.

Múltiples instancias de MVS pueden organizarse y administrarse colectivamente en una estructura llamada complejo de sistemas o sysplex, introducida en septiembre de 1990. Las instancias interoperan a través de un componente de software llamado Facilidad de acoplamiento entre sistemas (XCF) y un componente de hardware llamado Facilidad de acoplamiento de hardware (CF o Facilidad de acoplamiento integrada, ICF, si se ubican en el mismo hardware de mainframe). Se pueden unir varios sysplexes a través de protocolos de red estándar, como la arquitectura de red de sistemas (SNA) propiedad de IBM o, más recientemente, a través de TCP/IP. El sistema operativo z/OS (el descendiente más reciente de MVS) también tiene soporte nativo para ejecutar aplicaciones POSIX y Single UNIX Specification. El soporte comenzó con MVS/SP V4R3 e IBM obtuvo la certificación UNIX 95 para z/OS V1R2 y posteriores.

El sistema se usa normalmente en negocios y banca, y las aplicaciones a menudo se escriben en COBOL. Los programas COBOL se usaban tradicionalmente con sistemas de procesamiento de transacciones como IMS y CICS. Para un programa que se ejecuta en CICS, se insertan sentencias EXEC CICS especiales en el código fuente de COBOL. Un preprocesador (traductor) reemplaza esas declaraciones EXEC CICS con el código COBOL apropiado para llamar a CICS antes de compilar el programa, no muy diferente del SQL que se usa para llamar a DB2. Las aplicaciones también se pueden escribir en otros lenguajes como C, C++, Java, lenguaje ensamblador, FORTRAN, BASIC, RPG y REXX. La compatibilidad con idiomas se empaqueta como un componente común denominado "Entorno lingüístico" o "LE" para permitir la depuración uniforme, el seguimiento, la creación de perfiles y otras funciones independientes del idioma.

Los sistemas MVS se acceden tradicionalmente a través de terminales 3270 o PC que ejecutan emuladores 3270. Sin embargo, muchas aplicaciones de mainframe en estos días tienen interfaces web o GUI personalizadas. El sistema operativo z/OS tiene soporte incorporado para TCP/IP. La administración del sistema, que antes se realizaba con un terminal 3270, ahora se realiza mediante la Consola de administración de hardware (HMC) y, cada vez más, las interfaces web. Las consolas de operador se proporcionan a través de emuladores 2074, por lo que es poco probable que vea un procesador S/390 o zSeries con un 3270 real conectado.

El esquema de codificación de caracteres nativo de MVS y sus periféricos es EBCDIC, pero la instrucción TR facilitó la traducción a otros códigos de 7 y 8 bits. Con el tiempo, IBM agregó servicios acelerados por hardware para realizar la traducción hacia y entre códigos más grandes, servicio específico de hardware para transformaciones Unicode y soporte de software de, por ejemplo, ASCII, ISO/IEC 8859, UTF-8, UTF-16 y UTF-32.. Los servicios de traducción de software toman páginas de códigos de origen y de destino como entradas.

Sistema de archivos MVS

Los archivos, que no sean archivos Unix, se denominan correctamente conjuntos de datos en MVS. Los nombres de esos archivos están organizados en catálogos que son archivos VSAM en sí mismos.

Los nombres de conjuntos de datos (DSN, término de mainframe para nombres de archivo) se organizan en una jerarquía cuyos niveles se separan con puntos, p. "DEPT01.SYSTEM01.FILE01". Cada nivel de la jerarquía puede tener hasta ocho caracteres. La longitud total del nombre de archivo es un máximo de 44 caracteres, incluidos los puntos. Por convención, los componentes separados por puntos se utilizan para organizar archivos de manera similar a los directorios en otros sistemas operativos. Por ejemplo, había programas de utilidad que realizaban funciones similares a las del Explorador de Windows (pero sin la GUI y generalmente en modo de procesamiento por lotes): agregar, cambiar el nombre o eliminar nuevos elementos e informar todo el contenido de un elemento específico. Sin embargo, a diferencia de muchos otros sistemas, estos niveles no suelen ser directorios reales, sino simplemente una convención de nomenclatura (como el sistema de archivos original de Macintosh, donde la jerarquía de carpetas era una ilusión mantenida por el Finder). TSO admite un prefijo predeterminado para los archivos (similar a un concepto de "directorio actual"), y RACF admite la configuración de controles de acceso basados en patrones de nombres de archivos, de forma análoga a los controles de acceso en directorios en otras plataformas.

Al igual que con otros miembros de la familia OS, MVS' los conjuntos de datos estaban orientados a registros. MVS heredó tres tipos principales de sus predecesores:

• Los conjuntos de datos secuenciales normalmente se leen un registro a la vez de principio a fin.
• En los conjuntos de datos BDAM (acceso directo), el programa de aplicación tenía que especificar la ubicación física de los datos que quería acceder (generalmente especificando el offset desde el inicio del conjunto de datos).
• En los datos del ISAM se define una sección específica de cada registro como una clave que podría utilizarse como clave para buscar registros específicos. La clave con frecuencia consistía en múltiples campos, pero éstos tenían que ser contiguos y en el orden correcto; y los valores clave tenían que ser únicos. Por lo tanto, un archivo IBM ISAM podría tener sólo una clave, equivalente a la clave principal de una tabla de bases de datos relacionales; ISAM no podía soportar claves extranjeras.

Los conjuntos de datos secuenciales e ISAM pueden almacenar registros de longitud fija o de longitud variable, y todos los tipos pueden ocupar más de un volumen de disco.

Todos estos se basan en la estructura del disco VTOC.

Los primeros sistemas de administración de bases de datos de IBM usaban varias combinaciones de conjuntos de datos ISAM y BDAM, generalmente BDAM para el almacenamiento de datos real e ISAM para los índices.

A principios de la década de 1970, los sistemas operativos de memoria virtual de IBM introdujeron un nuevo componente de gestión de archivos, VSAM, que proporcionaba funciones similares:

• Datasets (ESDS) proporcionados instalaciones similares a las de conjuntos de datos secuenciales y BDAM, ya que pueden leerse de principio a fin o directamente especificando un offset desde el principio.
• Los conjuntos de datos secuenciados clave (KSDS) fueron una mejora importante de ISAM: permitieron claves secundarias con valores y claves no únicos formados por campos no contiguos concatenantes en cualquier orden; disminuyeron considerablemente los problemas de rendimiento causados por los registros de flujo en ISAM; y disminuyeron considerablemente el riesgo de que un fallo de software o hardware en el centro de una actualización de índice pudiera dañar el índice.

Estos formatos VSAM se convirtieron en la base de los sistemas de administración de bases de datos de IBM, IMS/VS y DB2, generalmente ESDS para el almacenamiento de datos real y KSDS para los índices.

VSAM también incluía un componente de catálogo utilizado para catálogos de usuarios y MVS' catálogo maestro.

Los conjuntos de datos particionados (PDS) eran conjuntos de datos secuenciales subdivididos en "miembros" cada uno podría procesarse como archivos secuenciales por derecho propio (como una carpeta en un sistema de archivos jerárquico). El uso más importante de PDSes fue para las bibliotecas de programas: los administradores del sistema usaban el PDS principal como una forma de asignar espacio en disco a un proyecto y el equipo del proyecto luego creaba y editaba los miembros. Otros usos de los PDS fueron bibliotecas de procedimientos de control de trabajos (PROC) de uso frecuente y "libros de copia" de sentencias de lenguaje de programación tales como definiciones de registro usadas por varios programas.

Los grupos de datos de generación (GDG) son grupos de conjuntos de datos con nombres similares, a los que se puede hacer referencia por número de generación absoluto o por una compensación de la generación más reciente. Originalmente, se diseñaron para admitir los procedimientos de copia de seguridad abuelo-padre-hijo: si se modificaba un archivo, la versión cambiada se convertía en el nuevo 'hijo', el anterior 'hijo'. se convirtió en el "padre", el anterior "padre" se convirtió en el "abuelo" y el anterior "abuelo" fué borrado. Pero uno podría configurar GDG con más de 3 generaciones y algunas aplicaciones usaron GDG para recopilar datos de varias fuentes y enviar la información a un programa: cada programa de recopilación creó una nueva generación del archivo y el programa final leyó todo el grupo como un único archivo secuencial (al no especificar una generación en el JCL).

Las versiones modernas de MVS (p. ej., z/OS) utilizan conjuntos de datos como contenedores para sistemas de archivos Unix junto con funciones para integrarlos parcialmente. Es decir, los programas de Unix que utilizan fopen() pueden acceder a un conjunto de datos de MVS y un usuario puede asignar un archivo de Unix como si fuera un conjunto de datos, con algunas restricciones. El Sistema de archivos jerárquicos (HFS) (que no debe confundirse con el Sistema de archivos jerárquicos de Apple) utiliza un tipo único de conjunto de datos, mientras que el Sistema de archivos z/OS (zFS) más reciente (que no debe confundirse con el Sistema de archivos jerárquico de Sun) s ZFS) utiliza un conjunto de datos lineales VSAM (LDS).

Los programas que se ejecutan en computadoras conectadas a la red (como IBM AS/400) pueden usar interfaces de administración de datos locales para crear, administrar y acceder de manera transparente a archivos orientados a registros VSAM mediante el uso de productos cliente-servidor implementados de acuerdo con la administración de datos distribuidos. Arquitectura (DDM). DDM también es la arquitectura base para el servidor MVS DB2 que implementa la arquitectura de base de datos relacional distribuida (DRDA).

Actualizaciones a MVS

Además de la nueva funcionalidad que IBM agregó con lanzamientos y sublanzamientos de OS/VS2, IBM proporcionó una cantidad de lanzamientos de cambio incremental (ICR) y unidades seleccionables (SU) gratuitos y productos de programas con cargo y programas desarrollados en el campo que IBM finalmente incluido como parte de z/OS. Éstos incluyen:

• ACF/TCAM (5735-RCl)
• ACF/VTAM (5746-RC3, 5735-RC2)
• Data Facility/Device Support (DF/DS), 5740-AM7
• Función ampliada del servicio de datos (DF/EF), 5740-XYQ
• Data Facility/Data Set Services (DF/DSS), 5740-UT3.
• Data Facility Sort, 5740-SM1
• OS/VS2 MVS Método de acceso secuencial (SAM-E), 5740-AM3
• MVS/370 Data Facility Product (DFP), 5665-295, replace
  • 5740-AM7 Apoyo a los dispositivos del servicio de datos
  • 5740-XYQ Función ampliada del servicio de datos
  • 5740-AM3 Método de acceso secuencial ampliado (SAM-E)
  • 5740-AM8 Access Method Services Cryptographic Option
  • 5748-UT2 Sin conexión 3800 Utilidad
• MVS/XA Data Facility Versión del producto 1 Release 1, 5665-284
• MVS/XA Data Facility Versión del producto 2 Release 1, 5665-XA2
• MVS/ESA Data Facility Versión 3, 5665-XA3
• Subsistema de Gestión del Almacenamiento de Datos (DFSMS), 5695-DF1
  Sustitúyase DFP, DF/DSS y DF/HSM
• OS/VS2 MVS TSO Command Package (5740-XT6)
• TSO Command Processor - FDP 5798-AYF (PRINT command)
• TSO/VS2 Programming Control Facility - FDP 5798-BBJ
• TSO Mecanismo de control de programación - II (PCF II), FDP 5798-CLW,
• TSO Extensiones
  Reemplaza el paquete de comandos TSO, procesador de comandos TSO y PCF
  • 5665-285 para MVS/370
  • 5665-293 para MVS/XA
  • 5685-025 para MVS/XA
    Primera versión con REXX
• OS/VS2 MVS/System Extensiones, 5740-XEl
• MVS/System Product
  • JES3 Versión 1 5740-XYN
  • JES2 Versión 1 5740-XYS
  • MVS/System Product-JES2 Version 2, 5740-XC6
  • MVS/System Product-JES3 Version 2, 5665-291
  • MVS/System Product-JES2 Version 3, 5685-001
  • MVS/System Product-JES3 Version 3, 5685-002
  • MVS/ESA System Product: JES2 Version 4, 5695-047
  • MVS/ESA System Product: JES3 Version 4, 5695-048
  • MVS/ESA System Product: JES2 Version 5, 5655-068
  • MVS/ESA System Product: JES3 Version 5, 5655-069

Producto de instalación de datos (DFP)

A finales de los setenta y principios de los ochenta, IBM anunció:

• 5740-AM7 Apoyo a los dispositivos del servicio de datos (DF/DS)
• 5740-XYQ Función ampliada del servicio de datos (DF/EF)
• 5740-AM3 Método de acceso secuencial ampliado (SAM-E)
• 5740-AM8 Access Method Services Cryptographic Option
• 5748-UT2 Sin conexión 3800 Utilidad

DF/DS agregó compatibilidad con nuevos dispositivos e IBM anunció que ya no agregaría compatibilidad con dispositivos a la base gratuita. DF/EF agregó la estructura de catálogo mejorada (ICF) como una alternativa a los catálogos VSAM y los volúmenes de control (CVOL), pero estaba plagado de problemas de confiabilidad.

Cuando IBM anunció MVS/SP Versión 2 (MVS/XA), también anunció Data Facility Product™ (DFP™) como reemplazo y actualización de los otros cinco productos anteriores, que dijo que serían retirados del marketing, efectivo el 1 de diciembre de 1984. DFP/370 Release 1 (número de programa 5665-295), anunciado el 7 de junio de 1983, era para MVS/SP Versión 1, MVS/SE y OS/VS2 R3.8, y era opcional, pero MVS /Extended Architecture Data Facility Product (5665-284) era un correquisito para MVS/SP Versión 2 (MVS/XA). Además de mejorar las funciones de administración de datos, DFP reemplazó las versiones gratuitas del editor de vínculos y las utilidades.

DFP ya no está disponible como un producto independiente, sino que se ha convertido en parte del subsistema de administración de almacenamiento de instalaciones de datos, bajo el nombre DFSMSdfp.

MVS moderna

MVS corriendo en el emulador de Hércules

MVS ahora se ha convertido en z/OS; IBM ya no admite las versiones anteriores de MVS y, desde 2007, solo se admiten las versiones de z/OS de 64 bits. z/OS admite la ejecución de aplicaciones MVS antiguas de 24 y 31 bits junto con aplicaciones más nuevas de 64 bits.

Las versiones de MVS hasta 3.8j (24 bits, lanzadas en 1981) estaban disponibles gratuitamente y ahora es posible ejecutar la versión MVS 3.8j en emuladores de mainframe de forma gratuita.

MVS/370

MVS/370 es un término genérico para todas las versiones del sistema operativo MVS anteriores a MVS/XA. La arquitectura System/370, en el momento en que se lanzó MVS, solo admitía direcciones virtuales de 24 bits, por lo que la arquitectura del sistema operativo MVS/370 se basa en una dirección de 24 bits. Debido a esta longitud de dirección de 24 bits, los programas que se ejecutan en MVS/370 reciben cada uno 16 MB de almacenamiento virtual contiguo.

MVS/XA

MVS/XA, o Almacenamiento virtual múltiple/arquitectura extendida, era una versión de MVS compatible con la arquitectura 370-XA, que tenía una nueva arquitectura de E/S. y también amplió las direcciones de 24 bits a 31 bits, proporcionando un área de memoria direccionable de 2 gigabytes. MVS/XA admitía un modo de direccionamiento heredado de 24 bits para aplicaciones más antiguas de 24 bits (es decir, aquellas que almacenaban una dirección de 24 bits en los 24 bits inferiores de una palabra de 32 bits y utilizaban los 8 bits superiores de esa palabra para otros fines).

MVS/ESA

MVS Enterprise System Architecture (MVS/ESA) es cualquier versión de MVS anterior a OS/390 compatible con S/370 Enterprise System Architecture (S/370-ESA). MVS/ESA amplía los modos de direccionamiento de 24 bits y 31 bits de MVS/XA al agregar un modo de registro de acceso (AR) para referencias entre espacios de direcciones.

IBM presentó MVS/ESA como MVS/SP Versión 3 en febrero de 1988, luego MVS/ESA SP Versión 4 y MVS/ESA SP Versión 5. IBM lo reemplazó con OS/390 a finales de 1995 y posteriormente con z/OS.

MVS/ESA OpenEdition: actualización a la versión 4 versión 3 de MVS/ESA anunciada en febrero de 1993 con soporte para POSIX y otros estándares. Si bien la versión inicial solo tenía la certificación del Instituto Nacional de Estándares y Tecnología (NIST) para el cumplimiento del Estándar federal de procesamiento de información (FIPS) 151, las versiones posteriores fueron certificadas en niveles más altos y por otras organizaciones, p. X/Open y su sucesor, The Open Group. Incluía alrededor de 1 millón de nuevas líneas de código, que proporcionan un shell de API, utilidades y una interfaz de usuario ampliada. Funciona con un sistema de archivos jerárquico proporcionado por DFSMS (Data Facility System Managed Storage). El shell y las utilidades se basan en Mortice Kerns' productos InterOpen. Especialistas independientes estiman que más del 80 % era compatible con los sistemas abiertos, más que la mayoría de los sistemas Unix. La compatibilidad con DCE2 se anunció en febrero de 1994 y muchas herramientas de desarrollo de aplicaciones en marzo de 1995. Desde mediados de 1995, cuando todas las características abiertas se convirtieron en una parte estándar de Vanilla MVS/ESA SP Versión 5 Release 1, IBM dejó de distinguir OpenEdition del sistema operativo. Bajo OS/390 V2R6 se convirtió en UNIX System Services y ha mantenido ese nombre bajo z/OS.

OS/390

A fines de 1995, IBM incluyó MVS con varios productos de programas y cambió el nombre de MVS/ESA a OS/390.

Z/OS

El nivel actual de MVS se comercializa como z/OS.

Sistemas operativos estrechamente relacionados

Los fabricantes japoneses de mainframe Fujitsu e Hitachi obtuvieron repetida e ilegalmente el código fuente MVS de IBM y la documentación interna en uno de los casos de espionaje industrial más famosos del siglo XX. Fujitsu se basó en gran medida en el código de IBM en su sistema operativo de mainframe MSP y, de la misma manera, Hitachi hizo lo mismo para su sistema operativo VOS3. MSP y VOS3 se comercializaron intensamente en Japón, donde todavía tienen una parte sustancial de la base instalada de mainframe, pero también hasta cierto punto en otros países, especialmente en Australia. Incluso los errores y errores ortográficos de la documentación de IBM se copiaron fielmente. IBM cooperó con la Oficina Federal de Investigaciones de EE. UU. en una operación encubierta, suministrando a regañadientes a Fujitsu y Hitachi tecnologías de hardware de mainframe y MVS patentadas durante el curso de investigaciones de varios años que culminaron a principios de la década de 1980, investigaciones que implicaron a altos directivos de la empresa e incluso a algunos japoneses. oficiales del gobierno. Amdahl, sin embargo, no estuvo involucrado en el robo de la propiedad intelectual de IBM por parte de Fujitsu. Todas las comunicaciones de Amdahl a Fujitsu se realizaron a través de "Especificaciones exclusivas de Amdahl" que se limpiaron escrupulosamente de cualquier IP de IBM o cualquier referencia a la IP de IBM.

Después de las investigaciones, IBM llegó a acuerdos multimillonarios tanto con Fujitsu como con Hitachi, recaudando fracciones sustanciales de ambas empresas. beneficios durante muchos años. Informes confiables indican que los acuerdos superaron los US$500.000.000.

Hace tiempo que las tres empresas acordaron amistosamente muchas empresas comerciales conjuntas. Por ejemplo, en 2000, IBM e Hitachi colaboraron en el desarrollo del modelo de mainframe IBM z900.

Debido a esta copia histórica, MSP y VOS3 se clasifican correctamente como "bifurcaciones" de MVS, y muchos proveedores de software de terceros con productos compatibles con MVS pudieron producir versiones compatibles con MSP y VOS3 con poca o ninguna modificación.

Cuando IBM presentó sus mainframes z/Architecture de 64 bits en el año 2000, IBM también presentó el sistema operativo z/OS de 64 bits, el sucesor directo de OS/390 y MVS. Fujitsu e Hitachi optaron por no licenciar IBM's z/Architecture para sus sistemas operativos y sistemas de hardware cuasi-MVS, por lo que MSP y VOS3, si bien nominalmente siguen siendo compatibles con sus proveedores, mantienen la mayoría de las limitaciones arquitectónicas de MVS de la década de 1980. hasta el día de hoy. Dado que z/OS aún es compatible con las aplicaciones y tecnologías de la era MVS, z/OS aún contiene la mayor parte del código de MVS, aunque mejorado y mejorado mucho durante décadas de evolución, las aplicaciones (y los procedimientos operativos) que se ejecutan en MSP y VOS3 pueden moverse a z/OS mucho más fácilmente que a otros sistemas operativos.