MVS

Multiple Virtual Storage ( MVS ) es el sistema operativo más utilizado en los ordenadores centrales System/370 , System/390 e IBM Z de IBM . IBM desarrolló MVS, junto con OS/VS1 y SVS , como sucesor de OS/360 . No guarda relación con las demás líneas de sistemas operativos para ordenadores centrales de IBM, como VSE , VM y TPF .

Lanzado por primera vez en 1974, MVS fue ampliado varias veces con productos de programas que adoptaron nuevos nombres, conservando el término MVS en la nomenclatura:

• primero a MVS/SE (MVS/Extensiones del sistema), ^{[ NB 1 ]}
• junto a MVS/SP (MVS/System Product) Versión 1,
• junto a MVS/XA (MVS/eXtended Architecture),
• junto a MVS/ESA (MVS/Arquitectura de Sistemas Empresariales),

y luego se extendió

• a OS/390 para los sistemas System/390 y
• Finalmente, en z/OS (cuando se añadió compatibilidad con 64 bits en los modelos zSeries ), IBM incorporó compatibilidad con UNIX (originalmente denominada OpenEdition MVS ) en MVS/SP V4.3 y obtuvo certificaciones POSIX y UNIX™ en distintos niveles de IEEE , X/Open y The Open Group . El núcleo de MVS sigue siendo fundamentalmente el mismo sistema operativo. Por diseño, los programas escritos para MVS se ejecutan en z/OS sin modificaciones.

Al principio, IBM describió MVS simplemente como una nueva versión de OS/VS2 , pero en realidad se trata de una reescritura importante. OS/VS2 versión 1 es una actualización de OS/360 MVT que conservó la mayor parte del código original y, al igual que MVT, está escrito principalmente en lenguaje ensamblador . El núcleo de MVS está escrito casi en su totalidad en Assembler XF , aunque algunos módulos se escribieron en PL/S , pero no los que son críticos para el rendimiento, en particular el Supervisor de Entrada/Salida (IOS). El uso que hizo IBM de "OS/VS2" enfatizaba la compatibilidad ascendente: los programas de aplicación que se ejecutaban bajo MVT ni siquiera necesitaban recompilarse para ejecutarse bajo MVS. Los mismos archivos del Lenguaje de Control de Trabajos podían usarse sin cambios; las utilidades y otras funciones no esenciales, como TSO, se ejecutaban sin cambios. IBM y los usuarios denominaron al nuevo sistema MVS casi unánimemente desde el principio, e IBM continuó utilizando el término MVS en la denominación de versiones principales posteriores , como MVS/XA.

OS/360 MFT (Multiprogramación con un número fijo de tareas) ^{[ 1 ]} proporciona multiprogramación : se configuran varias particiones de memoria , cada una de un tamaño fijo, cuando se instala el sistema operativo y cuando el operador las redefine. 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 liberara la partición grande. OS/360 R19 añadió subtareas MFT ( multitarea ), la capacidad de que un trabajo cree dinámicamente nuevas tareas con la macro ATTACH.

OS/360 MVT (Multiprogramación con un número variable de tareas) ^{[ 1 ]} fue una mejora que perfeccionó aún más el uso de la memoria. En lugar de usar particiones de memoria de tamaño fijo, MVT asigna memoria a regiones para los pasos de trabajo según sea necesario, siempre que haya suficiente memoria física contigua disponible. Esto representa un avance significativo con respecto a la gestión de memoria de MFT, pero tiene algunas debilidades: si un trabajo asigna memoria dinámicamente (como lo hacen la mayoría de los programas de ordenación y los sistemas de gestión de bases de datos ), los programadores deben estimar el requisito máximo de memoria del trabajo y predefinirlo para MVT. Un paso de trabajo que contiene una mezcla de programas pequeños y grandes desperdicia memoria mientras se ejecutan los programas pequeños. Lo más grave es que la memoria puede 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 la única solución era esperar a que algunos trabajos actuales terminaran antes de iniciar otros nuevos.

A principios de la década de 1970, IBM intentó mitigar estas dificultades introduciendo la memoria virtual (que IBM denominó "almacenamiento virtual"), la cual permitía a los programas solicitar espacios de direcciones mayores que la memoria física. Las implementaciones originales tenían un único espacio de direcciones virtuales , compartido por todos los trabajos. OS/VS1 era OS/360 MFT dentro de un único espacio de direcciones virtuales; OS/VS2 SVS era OS/360 MVT dentro de un único espacio de direcciones virtuales. Por lo tanto, OS/VS1 y SVS, en principio, tenían las mismas desventajas que MFT y MVT, pero los impactos eran menos graves porque los trabajos y los operadores podían solicitar particiones mucho mayores con una granularidad de 2 KiB (para OS/VS1) o regiones con una granularidad de 4 KiB (para SVS), y las solicitudes provenían de un espacio de direcciones de 16 MiB incluso si el almacenamiento físico era menor. Al igual que en OS/360 MVT, los usuarios de TSO en SVS se asignan a una región TSO durante el proceso de inicio de sesión y compiten con otros usuarios asignados a la misma región, con esencialmente la misma lógica de intercambio de entrada y salida que TSO en MVT.

A mediados de la década de 1970, IBM introdujo MVS, que no solo admitía almacenamiento virtual mayor que el almacenamiento real disponible, ^{[ NB 2 ]} como lo hacía SVS, sino que también permitía que un número ilimitado de aplicaciones se ejecutaran en diferentes espacios de direcciones. Dos programas concurrentes podían intentar acceder a la misma dirección de memoria virtual, pero el sistema de memoria virtual redirigía 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 empresariales derivados de la necesidad de ejecutar más aplicaciones.

MVS maximizó el potencial de procesamiento al proporcionar capacidades de multiprogramación y multiprocesamiento . ^{[ 2 ]} 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 se les asignan ciclos de procesamiento. 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 manera, el programa de control no tiene que esperar a que la operación de E/S se complete antes de continuar. Al ejecutar las instrucciones de múltiples programas, la computadora puede alternar entre programas activos e inactivos.

Las primeras versiones de MVS (mediados de la década de 1970) se encuentran entre las primeras series de sistemas operativos de IBM en admitir configuraciones multiprocesador , aunque la variante M65MP de OS/360, que se ejecutaba en los modelos 360 65 y 67, ofrecía un soporte multiprocesador limitado. El modelo 360 67 también albergaba los sistemas operativos TSS/360 , MTS y CP-67, compatibles con multiprocesadores . Dado que los sistemas multiprocesador pueden ejecutar instrucciones simultáneamente, ofrecen mayor potencia de procesamiento que los sistemas monoprocesadores. Como resultado, MVS pudo abordar los problemas empresariales derivados de la necesidad de procesar grandes cantidades de datos.

Los sistemas de multiprocesamiento pueden ser de acoplamiento débil, lo que significa que cada computadora tiene acceso a una carga de trabajo común, o de acoplamiento fuerte , lo que significa que las computadoras comparten el mismo almacenamiento real y son controladas por una sola copia del sistema operativo . MVS conservó tanto el multiprocesamiento de acoplamiento débil del Procesador de Soporte Adjunto (ASP) ^{[ NB 3 ]} como el multiprocesamiento de acoplamiento fuerte del Multiprocesamiento Modelo 65 de OS/360 . En los sistemas de acoplamiento fuerte, dos CPU compartían el acceso concurrente a la misma memoria (y copia del sistema operativo) y periféricos, lo que proporcionaba mayor potencia de procesamiento y un cierto grado de degradación gradual si una CPU fallaba. En las configuraciones de acoplamiento débil, cada uno de un grupo de procesadores (individuales y/o de acoplamiento fuerte) tenía su propia memoria y sistema operativo, pero compartía periféricos y el componente del sistema operativo JES3 permitía administrar todo el grupo desde una consola. Esto proporcionaba mayor resiliencia y permitía a los operadores decidir qué procesador debí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 mediante discos compartidos y adaptadores de canal a canal (CTCA). Esta capacidad posteriormente estuvo disponible para los usuarios de JES2 como SPOOL de acceso múltiple (MAS).

Originalmente, MVS admitía direccionamiento de 24 bits (es decir, hasta 16 MB). Con el avance del hardware subyacente, admitió direccionamiento de 31 bits (XA y ESA; hasta 2048 MB) y, actualmente (como z/OS), de 64 bits. Los motivos más importantes para la rápida actualización al direccionamiento de 31 bits fueron el crecimiento de grandes redes de procesamiento de transacciones, controladas principalmente por CICS , que operaban en un único espacio de direcciones; además, el sistema de gestión de bases de datos relacionales DB2 necesitaba más de 8 MB de espacio de direcciones de aplicación para funcionar de manera eficiente. (Las primeras versiones estaban configuradas 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 debían transmitirse a través del sistema operativo).

Las principales interfaces de usuario de MVS son: Job Control Language (JCL), diseñado originalmente para el procesamiento por lotes, pero que a partir de la década de 1970 también se utilizó para iniciar y asignar recursos a trabajos interactivos de larga duración como CICS ; y TSO (Time Sharing Option), 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 TSO para usuarios de terminales de la familia 3270 (y posteriormente, también en VM), que permite al usuario realizar las mismas tareas que la línea de comandos de TSO , pero de forma orientada a menús y formularios, 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 añadieron funcionalidades, como ISPF , para interfaces basadas en formularios. ^{[ 3 ]}

MVS dio un gran paso adelante en la tolerancia a fallos, basándose en la anterior funcionalidad STAE, que IBM denominó recuperación de software . IBM tomó esta decisión tras años de experiencia práctica con MVT en el mundo empresarial. Los fallos del sistema estaban teniendo un gran impacto en los negocios de los clientes, e IBM decidió dar un salto de diseño importante, partiendo de la premisa de que, a pesar de las mejores técnicas de desarrollo y prueba de software, «los problemas surgirán». Esta premisa fue fundamental para incorporar un alto porcentaje de código de tolerancia a fallos al sistema y probablemente contribuyó a su éxito en la tolerancia a fallos de software y hardware.

Este diseño especificaba una jerarquía de programas de manejo de errores, en modo sistema (núcleo/privilegiado), denominados Rutinas de Recuperación Funcional, y en modo usuario (tarea o programa problemático), denominados "ESTAE" (Rutinas de Salida Anormal de Tarea Especificada Extendida), que se invocan en caso de que el sistema detecte un error (error de hardware del procesador o del almacenamiento, o error de software). Cada rutina de recuperación permitía volver a invocar la función principal, capturaba datos de diagnóstico de errores suficientes para depurar el problema causante y, posteriormente, reintentaba (reinvocaba la función principal) o propagaba (escalaba el procesamiento de errores a la siguiente rutina de recuperación en la jerarquía).

Así, con cada error, el sistema capturaba datos de diagnóstico e intentaba repararlo para mantenerlo operativo. En caso de errores no reparados, lo peor que podía ocurrir era la interrupción del espacio de direcciones de usuario (un "trabajo"). Si bien este era un punto de diseño inicial, no fue hasta la versión más reciente de MVS (z/OS) que el programa de recuperación no solo contaba con su propia rutina de recuperación, sino que ahora cada rutina de recuperación dispone de la suya propia. Esta estructura de recuperación se integró en el programa de control básico de MVS, y los desarrolladores de aplicaciones y de terceros disponen de herramientas de programación que pueden utilizar.

En la práctica, la recuperación de software de MVS hizo que la depuración de problemas fuera a la vez más fácil y más difícil. La recuperación de software requiere que los programas dejen rastros de su ubicación y actividad, lo que facilita la depuración; sin embargo, el hecho de que el procesamiento continúe a pesar de un error puede sobrescribir dichos rastros. La captura temprana de datos en el momento del error maximiza la depuración, y existen mecanismos para que las rutinas de recuperación (tanto en modo tarea como en modo sistema) realicen esta tarea.

IBM incluyó criterios adicionales para determinar si un problema grave de software requería su servicio. Si un componente principal no lograba iniciar la recuperación del software, se consideraba un fallo válido que debía notificarse. Asimismo, si una rutina de recuperación no recopilaba datos de diagnóstico significativos, de modo que el problema original no pudiera resolverse con los datos recopilados por dicha rutina, los estándares de IBM dictaban que este fallo debía notificarse y requería reparación. Por lo tanto, los estándares de IBM, cuando se aplicaban rigurosamente, fomentaban la mejora continua.

IBM continuó brindando soporte a la principal herramienta de mantenimiento, el Sistema de Soporte Dinámico ^{[ 4 ]} (DSS), que había introducido en OS/VS1 y OS/VS2 Release 1. Esta herramienta interactiva podía invocarse para iniciar una sesión y crear procedimientos de diagnóstico, o para invocar procedimientos ya almacenados. Los procedimientos capturaban eventos especiales, como la carga de un programa, la E/S de dispositivos y las llamadas a procedimientos del sistema, y ​​luego activaban los procedimientos definidos previamente. Estos procedimientos, que podían invocarse recursivamente, permitían la lectura y escritura de datos, así como la modificación del flujo de instrucciones. Se utilizó hardware de grabación de eventos de programa.

IBM dejó de dar soporte a DSS con la Unidad Selectable 7 (SU7), una actualización de OS/VS2 Release 3.7 necesaria para el producto OS/VS2 MVS/System Extensions (MVS/SE), número de programa 5740-XEl. El grupo de usuarios SHARE aprobó una solicitud para que IBM restableciera el soporte para DSS, y IBM proporcionó un PTF para permitir el uso de DSS después de la instalación de MVS/SE.

IBM volvió a dejar de dar soporte a DSS con SU64, una actualización de OS/VS2 Release 3.8 necesaria para la versión 2 de MVS/SE.

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

Varias copias de MVS (u otros sistemas operativos de IBM) podían compartir la misma máquina si esta estaba controlada por VM/370 . En este caso, VM/370 era el sistema operativo real y consideraba a los sistemas operativos "invitados" como aplicaciones con privilegios excepcionalmente altos. Gracias a mejoras posteriores del hardware, una instancia de un sistema operativo (ya sea MVS, una máquina virtual con invitados u otro) también podía ocupar una partición lógica (LPAR) en lugar de todo el sistema físico.

Varias instancias de MVS pueden organizarse y administrarse colectivamente en una estructura denominada complejo de sistemas o sysplex , introducida en septiembre de 1990. Las instancias interoperan mediante un componente de software llamado Cross-system Coupling Facility (XCF) y un componente de hardware llamado Hardware Coupling Facility (CF o Integrated Coupling Facility, ICF, si se encuentran en el mismo hardware de mainframe). Varios sysplexes pueden unirse mediante protocolos de red estándar como la arquitectura de red de sistemas (SNA) propietaria de IBM o, más recientemente, mediante TCP/IP . El sistema operativo z/OS (el descendiente más reciente de MVS) también cuenta con soporte nativo para ejecutar aplicaciones POSIX y Single UNIX Specification . Este soporte comenzó con MVS/SP V4R3, e IBM ha obtenido la certificación UNIX 95 para z/OS V1R2 y versiones posteriores. ^{[ 5 ]}

El sistema se utiliza habitualmente en el ámbito empresarial y bancario, y las aplicaciones suelen estar escritas en COBOL . Los programas COBOL se utilizaban tradicionalmente con sistemas de procesamiento de transacciones como IMS y CICS . Para un programa que se ejecuta en CICS, se insertan instrucciones EXEC CICS especiales en el código fuente COBOL. Un preprocesador (traductor) reemplaza esas instrucciones EXEC CICS con el código COBOL apropiado para llamar a CICS antes de la compilación del programa  , de forma similar a como se utiliza SQL para llamar a DB2 . Las aplicaciones también pueden escribirse en otros lenguajes como C , C++ , Java , lenguaje ensamblador , FORTRAN , BASIC , RPG y REXX . La compatibilidad con lenguajes se incluye como un componente común denominado "Entorno de Lenguaje" o "LE" para permitir la depuración, el seguimiento, la creación de perfiles y otras funciones independientes del lenguaje de forma uniforme.

Tradicionalmente, se accede a los sistemas MVS mediante terminales 3270 o PC con emuladores 3270. Sin embargo, muchas aplicaciones de mainframe actuales cuentan con interfaces web o gráficas personalizadas . El sistema operativo z/OS ofrece soporte integrado para TCP/IP . La administración del sistema, que antes se realizaba con un terminal 3270, ahora se lleva a cabo mediante la Consola de Administración de Hardware (HMC) y, cada vez más, mediante interfaces web. Las consolas de operador se proporcionan a través de emuladores 2074, por lo que es improbable encontrar un procesador S/390 o zSeries con un terminal 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 añadió servicios acelerados por hardware para realizar traducciones hacia y entre códigos más extensos, un servicio específico de hardware para transformaciones Unicode y soporte de software para, por ejemplo, ASCII , ISO/IEC 8859 , UTF-8 , UTF-16 y UTF-32 . Los servicios de traducción de software toman como entrada las páginas de códigos de origen y destino.

En MVS , los archivos que no son de tipo Unix se denominan correctamente conjuntos de datos . Los nombres de estos archivos se organizan en catálogos que, a su vez, son archivos VSAM .

Los nombres de conjuntos de datos (DSN, término de mainframe para nombres de archivo) se organizan en una jerarquía cuyos niveles están separados por puntos, por ejemplo, "DEPT01.SYSTEM01.FILE01". Cada nivel de la jerarquía puede tener hasta ocho caracteres. La longitud total del nombre de archivo es de un máximo de 44 caracteres, incluidos los puntos. Por convención, los componentes separados por puntos se utilizan para organizar archivos de forma similar a los directorios en otros sistemas operativos. Por ejemplo, existen programas de utilidad que realizan funciones similares a las del Explorador de Windows (pero sin la interfaz gráfica de usuario y generalmente en modo de procesamiento por lotes ): agregar, renombrar o eliminar nuevos elementos e informar sobre todo el contenido de un elemento específico. Sin embargo, a diferencia de muchos otros sistemas, estos niveles no suelen ser ^{directorios reales ,} sino solo 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 al concepto de "directorio actual"), y RACF admite la configuración de controles de acceso basados ​​en patrones de nombres de archivo, de forma análoga a los controles de acceso a directorios en otras plataformas.

Al igual que otros miembros de la familia de sistemas operativos, los conjuntos de datos de MVS están orientados a registros . MVS heredó tres tipos principales de sus predecesores:

• Los conjuntos de datos secuenciales normalmente se leían registro por registro, de principio a fin.
• En los conjuntos de datos BDAM (acceso directo), el programa de aplicación debía especificar la ubicación física de los datos a los que quería acceder (normalmente especificando el desplazamiento desde el inicio del conjunto de datos).
• En los conjuntos de datos ISAM, una sección específica de cada registro se definía como una clave que permitía buscar registros concretos. Esta clave solía constar de varios campos , pero estos debían ser contiguos y estar en el orden correcto; además, los valores de la clave debían ser únicos. Por lo tanto, un archivo ISAM de IBM solo podía tener una clave, equivalente a la clave primaria de una tabla de base de datos relacional ; ISAM no admitía claves foráneas .

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

Todos ellos se basan en la estructura de disco VTOC .

Los primeros sistemas de gestión de bases de datos de IBM utilizaban diversas combinaciones de conjuntos de datos ISAM y BDAM; normalmente, BDAM se utilizaba para el almacenamiento de datos propiamente dicho 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 funcionalidades similares:

• Los conjuntos de datos secuenciados por entrada (ESDS) ofrecían funcionalidades similares a las de los conjuntos de datos secuenciales y BDAM, ya que podían leerse de principio a fin o directamente especificando un desplazamiento desde el inicio.
• Los conjuntos de datos secuenciados por clave (KSDS) representan una mejora importante con respecto a ISAM: permiten claves secundarias con valores no únicos y claves formadas mediante la concatenación de campos no contiguos en cualquier orden; redujeron considerablemente los problemas de rendimiento causados ​​por los registros de desbordamiento en ISAM; y redujeron considerablemente el riesgo de que un fallo de software o hardware en medio de una actualización del índice pudiera corromperlo.

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

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

Los conjuntos de datos particionados (PDS) son conjuntos de datos secuenciales subdivididos en "miembros", cada uno de los cuales puede procesarse como un archivo secuencial independiente (como una carpeta en un sistema de archivos). El uso más importante de los PDS era para bibliotecas de programas: los administradores de sistemas utilizaban el PDS principal para asignar espacio en disco a un proyecto, y el equipo del proyecto creaba y editaba los miembros. Otros usos de los PDS son las bibliotecas de procedimientos de control de trabajos (PROC) de uso frecuente y los "libros de copias" de instrucciones de lenguajes de programación, como las definiciones de registros utilizadas por varios programas.

Los grupos de datos de generación (GDG) son grupos de conjuntos de datos con el mismo nombre, a los que se puede hacer referencia mediante el número de generación absoluto o mediante un desplazamiento desde la generación más reciente. Originalmente, se diseñaron para admitir procedimientos de copia de seguridad de abuelo-padre-hijo : si se modificaba un archivo, la versión modificada se convertía en el nuevo "hijo", el "hijo" anterior en el "padre", el "padre" anterior en el "abuelo" y el "abuelo" anterior se eliminaba. Sin embargo, se podían configurar GDG con más de 3 generaciones, y algunas aplicaciones utilizaban GDG para recopilar datos de varias fuentes y alimentar la información a un solo programa: cada programa de recopilación creaba una nueva generación del archivo y el programa final leía todo el grupo como un único archivo secuencial (sin especificar una generación en el JCL ).

Las versiones modernas de MVS (por ejemplo, z/OS) utilizan conjuntos de datos como contenedores para sistemas de archivos Unix, junto con funcionalidades para integrarlos parcialmente. Es decir, los programas Unix que utilizan fopen() pueden acceder a un conjunto de datos MVS y un usuario puede asignar un archivo Unix como si fuera un conjunto de datos, con algunas restricciones ^{[ NB 5 ]} . El Sistema de Archivos Jerárquico (HFS) (que no debe confundirse con el Sistema de Archivos Jerárquico 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 ZFS de Sun ) utiliza un Conjunto de Datos Lineal (LDS) VSAM.

Los programas que se ejecutan en ordenadores conectados a la red (como el IBM AS/400 ) pueden usar interfaces de gestión de datos locales para crear, gestionar y acceder de forma transparente a archivos orientados a registros VSAM mediante productos cliente-servidor implementados según la Arquitectura de Gestión de Datos Distribuidos (DDM). DDM es también la arquitectura base del servidor MVS DB2 , que implementa la Arquitectura de Base de Datos Relacional Distribuida (DRDA).

Además de la nueva funcionalidad que IBM agregó con las versiones y subversiones de OS/VS2, IBM proporcionó una serie de versiones de cambios incrementales (ICR) y unidades seleccionables (SU) gratuitas, así como productos de programas de pago y programas desarrollados en campo que IBM finalmente incluyó como parte de z/OS. Estos incluyen:

• ACF/TCAM (5735-RCl)
• ACF/VTAM (5746-RC3, 5735-RC2)
• Soporte para dispositivos/instalaciones de datos (DF/DS), 5740-AM7
• Instalación de datos con funciones extendidas (DF/EF), 5740-XYQ
• Servicios de instalación/conjunto de datos (DF/DSS), 5740-UT3.
• Clasificación de instalaciones de datos, 5740-SM1
• Método de acceso secuencial extendido (SAM-E) OS/VS2 MVS, 5740-AM3
• Producto de centro de datos (DFP) MVS/370 , 5665-295, que reemplaza
  • 5740-AM7 Soporte para dispositivos de centro de datos (DFDS)
  • 5740-XYQ Función extendida de la instalación de datos (DFEF)
  • 5740-AM3 Método de acceso secuencial extendido (SAM-E)
  • 5740-AM8 Servicios de método de acceso Opción criptográfica
  • 5748-UT2 Utilidad 3800 sin conexión
• MVS/XA Data Facility Product Versión 1 Release 1, 5665-284
• Producto MVS/XA Data Facility Versión 2, Edición 1, 5665-XA2
• Producto de la plataforma de datos MVS/ESA, versión 3, 5665-XA3
• Subsistema de gestión de almacenamiento de instalaciones de datos (DFSMS), 5695-DF1. Reemplaza a DFP, DF/DSS y DF/HSM.
• Paquete de comandos OS/VS2 MVS TSO (5740-XT6)
• Procesador de comandos TSO - FDP 5798-AYF (comando PRINT)
• Instalación de control de programación TSO/VS2 - FDP 5798-BBJ
• Instalación de control de programación TSO - II (PCF II), FDP 5798-CLW,
• Las extensiones de TSO reemplazan el paquete de comandos de TSO, el procesador de comandos de 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/Extensiones del sistema, 5740-XEl
• Producto MVS/Sistema
  • JES3 Versión 1 5740-XYN
  • JES2 Versión 1 5740-XYS
  • MVS/Sistema Producto-JES2 Versión 2, 5740-XC6
  • MVS/Sistema Producto-JES3 Versión 2, 5665-291
  • MVS/Sistema Producto-JES2 Versión 3, 5685-001
  • MVS/Sistema Producto-JES3 Versión 3, 5685-002
  • Producto del sistema MVS/ESA: JES2 Versión 4, 5695-047
  • Producto del sistema MVS/ESA: JES3 Versión 4, 5695-048
  • Producto del sistema MVS/ESA: JES2 Versión 5, 5655-068
  • Producto del sistema MVS/ESA: JES3 Versión 5, 5655-069

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

• 5740-AM7 Soporte para dispositivos de centro de datos (DF/DS)
• 5740-XYQ Instalación de datos con funciones extendidas (DF/EF)
• 5740-AM3 Método de acceso secuencial extendido (SAM-E)
• 5740-AM8 Servicios de método de acceso Opción criptográfica
• 5748-UT2 Utilidad 3800 sin conexión

DF/DS añadió compatibilidad con nuevos dispositivos, e IBM anunció que dejaría de añadir compatibilidad con dispositivos a la versión gratuita. DF/EF incorporó la Estructura de Catálogo Mejorada (ICF) como alternativa a los catálogos VSAM y los volúmenes de control (CVOL), pero presentaba numerosos problemas de fiabilidad.

Cuando IBM anunció ^{[ 6 ]} MVS/SP Versión 2 (MVS/XA), también anunció ^{[ 7 ]} Data Facility Product™ (DFP™) como reemplazo y actualización de los otros cinco productos anteriores, que dijo que se retirarían del mercado, 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 requisito previo 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 enlaces y utilidades.

DFP ya no está disponible como producto independiente, sino que se ha integrado en el subsistema de gestión de almacenamiento de Data Facility , bajo el nombre DFSMSdfp .

MVS ha evolucionado hasta convertirse en z/OS; IBM ya no ofrece soporte para las versiones anteriores de MVS y, desde 2007, solo se admiten las versiones de z/OS de 64 bits. z/OS permite ejecutar aplicaciones MVS antiguas de 24 y 31 bits junto con aplicaciones más recientes de 64 bits.

Las versiones de MVS hasta la 3.8j (24 bits, lanzada en 1981) estaban disponibles gratuitamente y ahora es posible ejecutar la versión MVS 3.8j en emuladores de mainframe de forma gratuita, como el emulador Hercules . ^{[ 8 ]}

MVS/370 es un término genérico para todas las versiones del sistema operativo MVS anteriores a MVS/XA. ^{[ NB 6 ]} La arquitectura System/370 , en el momento del lanzamiento de 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, a los programas que se ejecutan en MVS/370 se les asignan 16  MB de almacenamiento virtual contiguo.

MVS/XA , o Multiple Virtual Storage/Extended Architecture , era una versión de MVS que admitía la arquitectura 370-XA  , la cual tenía una nueva arquitectura de E/S y también expandía las direcciones de 24 bits a 31  bits, proporcionando un área de memoria direccionable de 2 gigabytes . ^{[ 9 ]} MVS/XA admitía un modo de direccionamiento heredado de 24 bits para aplicaciones 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).   

La arquitectura de sistemas empresariales MVS ( MVS/ESA ) es cualquier versión de MVS anterior a OS/390 que admite la arquitectura de sistemas empresariales S/370 (S/370-ESA). MVS/ESA amplía los modos de direccionamiento de 24 y 31 bits de MVS/XA mediante la adición de un modo de registro de acceso (AR) para referencias entre espacios de direcciones.

IBM introdujo ^{[ 10 ]} MVS/ESA como MVS/SP Versión 3 en febrero de 1988, luego MVS/ESA SP Versión 4 ^{[ 11 ]} y MVS/ESA SP Versión 5. ^{[ 12 ]} IBM lo reemplazó con OS/390 ^{[ 13 ] [ 14 ]} a finales de 1995 y posteriormente con z/OS .

MVS/ESA OpenEdition: actualización a la versión 4 Release 3 de MVS/ESA SP anunciada ^{[ 15 ]} febrero de 1993 con soporte para POSIX y otros estándares. ^{[ 16 ] [ 17 ] [ 18 ]} 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, por ejemplo, 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 API, utilidades y una interfaz de usuario extendida. Funciona con un sistema de archivos jerárquico proporcionado por DFSMS (Data Facility System Managed Storage). El shell y las utilidades se basan en los productos InterOpen de Mortice Kerns . Especialistas independientes estiman que era más del 80% compatible con sistemas abiertos, más que la mayoría de los sistemas Unix. El soporte para 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 parte estándar de 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 , ^{[ 19 ] [ 20 ]} y ha mantenido ese nombre bajo z/OS .

A finales de 1995, IBM incluyó MVS en varios productos de software y cambió el nombre de MVS/ESA a OS/390.

La versión actual de MVS se comercializa como z/OS.

Los fabricantes japoneses de mainframes Fujitsu y Hitachi obtuvieron de forma reiterada e ilegal el código fuente y la documentación interna del sistema operativo MVS de IBM en uno de los casos de espionaje industrial más famosos del siglo XX . ^{[ 21 ]} Fujitsu dependía en gran medida del código de IBM en su sistema operativo para mainframes MSP , y de igual manera Hitachi hizo lo mismo para su sistema operativo VOS3. MSP y VOS3 se comercializaron intensamente en Japón, donde aún mantienen una participación sustancial en la base instalada de mainframes, pero también en cierta medida en otros países, especialmente en Australia. Incluso los errores y las faltas de ortografía en la documentación de IBM fueron copiados fielmente. IBM cooperó con el FBI en una operación encubierta , suministrando a regañadientes a Fujitsu y Hitachi tecnologías de hardware de mainframes y MVS patentadas durante el transcurso de investigaciones que duraron varios años y culminaron a principios de la década de 1980; investigaciones que implicaron a altos directivos de la empresa e incluso a algunos funcionarios del gobierno japonés. Sin embargo, Amdahl no estuvo involucrada en el robo de 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", las cuales fueron cuidadosamente depuradas de cualquier propiedad intelectual de IBM o referencia a la misma.

Tras las investigaciones, IBM llegó a acuerdos multimillonarios con Fujitsu y Hitachi, obteniendo una parte sustancial de las ganancias de ambas compañías durante muchos años. Informes fidedignos indican que los acuerdos superaron los 500.000.000 de dólares estadounidenses. ^{[ 22 ] [ 21 ] [ NB 7 ]}

Las tres compañías han acordado amistosamente desde hace tiempo numerosas colaboraciones empresariales. Por ejemplo, en el año 2000, IBM y Hitachi colaboraron en el desarrollo del modelo de ordenador central 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. ^{[ 23 ] [ 24 ] [ 25 ]}

Cuando IBM presentó sus mainframes z/Architecture de 64 bits en el año 2000, también presentó el sistema operativo z/OS de 64 bits, sucesor directo de OS/390 y MVS. Fujitsu y Hitachi optaron por no licenciar la arquitectura z/Architecture de IBM para sus sistemas operativos y hardware basados ​​en MVS, por lo que MSP y VOS3, si bien aún cuentan con soporte nominal por parte de sus proveedores, conservan 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 admite aplicaciones y tecnologías de la era MVS (z/OS todavía contiene la mayor parte del código de MVS, aunque considerablemente mejorado y perfeccionado a lo largo de décadas de evolución), las aplicaciones (y los procedimientos operativos) que se ejecutan en MSP y VOS3 pueden migrar a z/OS con mucha más facilidad que a otros sistemas operativos.

• OS/360 y sucesores#Cronología
• Hercules , un emulador de S/370, S/390 y zSeries capaz de ejecutar MVS.
• Programas de utilidad suministrados con los sistemas operativos MVS (y sucesores)
• BatchPipes es una utilidad de procesamiento de trabajos por lotes diseñada para el sistema operativo MVS/ESA y todas sus versiones posteriores: OS/390 y z/OS .

• IBM: Manuales de z/OS V1R11.0 MVS en Wayback Machine (archivado el 5 de septiembre de 2009)
• IBM: Manuales de z/OS V1R8.0 MVS en Wayback Machine (archivados el 4 de noviembre de 2006)
• MVS: el sistema operativo que mantiene el mundo en marcha en la Wayback Machine (archivado el 30/06/2001)
• MVS... una larga historia en Wayback Machine (archivado el 16/07/2001)
• AL Scherr (diciembre de 1973). "Estructura funcional de los sistemas operativos de almacenamiento virtual de IBM Parte II: conceptos y filosofías de OS/VS2-2". IBM Systems Journal . 12 (4). IBM: 382–400 . doi : 10.1147/sj.124.0382 .