El almacenamiento virtual múltiple , más comúnmente llamado MVS , es el sistema operativo más utilizado en las computadoras centrales IBM System /370 , System/390 e IBM Z. 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 .
Lanzado por primera vez en 1974, MVS se amplió con productos de programa con nuevos nombres varias veces, conservando el término MVS en la nomenclatura:
y luego extendido
Al principio, IBM describió MVS simplemente como una nueva versión de OS/VS2 , pero en realidad es una reescritura importante. OS/VS2 versión 1 es una actualización de OS/360 MVT que conserva 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 sensibles al rendimiento, en particular el Supervisor de entrada/salida (IOS). El uso de "OS/VS2" por parte de IBM 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 se pueden utilizar sin cambios; Los servicios públicos y otras instalaciones complementarias 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 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 : varias particiones de memoria , cada una de un tamaño fijo, se configuran 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 abandonara la partición grande. OS/360 R19 agregó la subtarea 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 refinó aún más el uso de la memoria. En lugar de utilizar particiones de memoria de tamaño fijo, MVT asigna memoria a regiones para los pasos del trabajo según sea necesario, siempre que haya suficiente memoria física contigua disponible. Este es un avance significativo sobre 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 clasificación y sistemas de gestión de bases de datos ), los programadores tienen que estimar el requisito máximo de memoria del trabajo y predefinirlo para MVT. . Un paso de trabajo que contiene una combinación 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 pequeños fragmentos inútiles entre las áreas utilizadas por los trabajos actuales, y el único remedio era esperar hasta que algunos trabajos actuales terminaran antes de comenzar otros nuevos.
A principios de la década de 1970, IBM intentó mitigar estas dificultades introduciendo la memoria virtual (que IBM llamó "almacenamiento virtual"), que 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 es 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. Entonces, OS/VS1 y SVS tenían en principio las mismas desventajas que MFT y MVT, pero los impactos son menos severos porque los trabajos y los operadores podrí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 surgieron de un espacio de direcciones de 16MiB 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 asignan a una región de TSO durante el procesamiento 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 sólo admitía almacenamiento virtual mayor que el almacenamiento real disponible, [NB 2] 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 empresariales que surgieron 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 reciben ciclos de procesamiento. A diferencia de un sistema operativo de programación única, estos sistemas maximizan el uso del potencial de procesamiento dividiendo 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 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) se encuentran entre las primeras de la serie IBM OS que admiten configuraciones multiprocesador , aunque la variante M65MP de OS/360 que se ejecuta en 360 modelos 65 y 67 había proporcionado soporte multiprocesador limitado. El 360 Modelo 67 también albergaba los sistemas operativos TSS/360 , MTS y CP-67 con capacidad multiprocesador. Debido a que los sistemas multiprocesamiento pueden ejecutar instrucciones simultáneamente, ofrecen mayor [ se necesita aclaración ] poder 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 multiprocesamiento están débilmente 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 controladas por una única copia del sistema operativo . [ se necesita aclaración ] MVS retuvo tanto el multiprocesamiento débilmente acoplado del procesador de soporte adjunto (ASP) [NB 3] como el multiprocesamiento estrechamente acoplado del multiprocesamiento OS/360 Modelo 65 . En sistemas estrechamente acoplados, dos CPU compartían acceso simultáneo a la misma memoria (y copia del sistema operativo) y periféricos, lo que proporcionaba una mayor potencia de procesamiento y un grado de degradación elegante si una CPU fallaba. En configuraciones débilmente acopladas, cada miembro de un grupo de procesadores (simple y/o estrechamente acoplado) 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 proporcionó una mayor resiliencia y permitió 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 a través de discos compartidos y adaptadores de canal a canal (CTCA). Esta capacidad finalmente estuvo disponible para los usuarios de JES2 como SPOOL de acceso múltiple (MAS). [ cita necesaria ]
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 importantes 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 único espacio de direcciones, y el sistema de gestión de bases de datos relacionales DB2 necesitaba más de 8 MB de direcciones de aplicaciones. espacio para funcionar eficientemente. (Las primeras versiones se configuraban 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 para MVS son: Job Control Language (JCL), que fue diseñado originalmente para el procesamiento por lotes , pero 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 del usuario final. ISPF es una aplicación TSO para usuarios de terminales de la familia 3270 (y posteriores, 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, y con un editor de pantalla completa. y explorador de archivos. La interfaz básica de TSO es la línea de comandos , aunque posteriormente se agregaron funciones, como ISPF , para interfaces basadas en formularios. [3]
MVS dio un gran paso adelante en la tolerancia a fallos, basándose en la instalació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 impactos importantes en los negocios de los clientes, e IBM decidió dar un salto importante en el diseño, para asumir que a pesar de las mejores técnicas de prueba y desarrollo de software, "los problemas OCURRIRÁN". Esta profunda suposición fue fundamental para agregar grandes porcentajes de código de tolerancia a fallas al sistema y probablemente contribuyó al éxito del sistema en la tolerancia de fallas de software y hardware. Es difícil conseguir información estadística que demuestre el valor de estas características de diseño (¿cómo se pueden medir los problemas 'prevenidos' o 'recuperados'?), pero IBM ha mejorado, en muchas dimensiones, estas recuperación de software tolerante a fallas y resolución rápida de problemas. características, con el tiempo.
Este diseño especificaba una jerarquía de programas de manejo de errores, en modo de sistema (núcleo/'privilegiado'), llamado Rutinas de Recuperación Funcional, y en modo de usuario ('tarea' o 'programa problemático'), llamado "ESTAE" (Tarea Especificada Extendida). Rutinas de salida anormales) que se invocan en caso de que el sistema detecte un error (procesador de hardware o error de almacenamiento, o error de software). Cada rutina de recuperación hacía que la función 'línea principal' fuera reinvocable, capturaba datos de diagnóstico de errores suficientes para depurar el problema que causaba y 'reintentaba' (reinvocaba la línea principal) o 'filtraba' (procesamiento de errores 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 que se podía hacer era eliminar un espacio de direcciones de usuario (un 'trabajo') en caso de errores no reparados. Aunque fue 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 tenía garantizada 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 estaba integrada en el programa de control básico de MVS, y los desarrolladores de programas de aplicaciones y desarrolladores externos utilizan las funciones de programación.
En la práctica, la recuperación del software MVS hizo que la depuración de problemas fuera más fácil y más difícil. 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 avance 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 funciones para que las rutinas de recuperación (modo de tarea y sistema, ambos) hagan esto.
IBM incluyó criterios adicionales para un problema de software importante que requería el servicio de IBM. Si un componente principal no lograba iniciar la recuperación del software, se consideraba una falla reportable válida. Además, si una rutina de recuperación no lograba recopilar datos de diagnóstico significativos, de modo que el problema original pudiera resolverse mediante 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 tanto, los estándares de IBM, cuando se aplicaban rigurosamente, fomentaban la mejora continua.
IBM continuó brindando soporte a la principal herramienta de servicio Dynamic Support System [4] (DSS) que había introducido en OS/VS1 y OS/VS2 Release 1. Esta función interactiva podría invocarse para iniciar una sesión para crear procedimientos de diagnóstico, o invocar ya -procedimientos almacenados. Los procedimientos capturaron eventos especiales, como la carga de un programa, E/S de dispositivos, llamadas a procedimientos del sistema y luego desencadenaron la activación de los procedimientos previamente definidos. Estos procedimientos, que podían invocarse de forma recursiva, permitían la lectura y escritura de datos y la alteración del flujo de instrucciones. Se utilizó hardware de grabación de eventos del programa.
IBM abandonó el soporte para DSS con Selectable Unit 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 nuevamente abandonó el soporte para 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).
Varias copias de MVS (u otros sistemas operativos de IBM) podrían compartir la misma máquina si esa máquina estuviera 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 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.
Se pueden organizar y administrar colectivamente varias instancias de MVS 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 Instalación de acoplamiento entre sistemas (XCF) y un componente de hardware llamado Instalación de acoplamiento de hardware. (CF o Instalación de Acoplamiento Integrado, ICF, si está ubicada en el mismo hardware de mainframe). Se pueden unir múltiples sysplex 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 de especificación única UNIX . El soporte comenzó con MVS/SP V4R3 e IBM obtuvo la certificación UNIX 95 para z/OS V1R2 y posteriores. [5]
El sistema se utiliza normalmente en negocios y banca, 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 sentencias EXEC CICS especiales en el código fuente 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 utilizado 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 . El soporte de idiomas está empaquetado como un componente común llamado "Language Environment" o "LE" para permitir una depuración uniforme, seguimiento, creación de perfiles y otras funciones independientes del idioma.
Tradicionalmente, se accede a los sistemas MVS mediante terminales 3270 o mediante PC que ejecutan emuladores 3270. Sin embargo, muchas aplicaciones de mainframe hoy en día tienen interfaces GUI o web personalizadas . El sistema operativo z/OS tiene soporte integrado para TCP/IP . La gestión del sistema, que antes se realizaba con un terminal 3270, ahora se realiza a través de la Consola de gestión de hardware (HMC) y, cada vez más, a través de interfaces web. Las consolas de operador se proporcionan a través de emuladores 2074, por lo que es poco probable que vea algún 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 traducciones hacia y entre códigos más grandes, servicios específicos 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 como entrada las páginas de códigos de origen y destino.
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 .
Los nombres de conjuntos de datos (DSN, término de mainframe para nombres de archivos) están organizados 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 manera 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 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 Macintosh original , donde la jerarquía de carpetas era una ilusión mantenida por el Finder). TSO admite un prefijo predeterminado para archivos (similar al concepto de "directorio actual") y RACF admite la configuración de controles de acceso basados en patrones de nombres de archivos, análogos a los controles de acceso a directorios en otras plataformas.
Al igual que con 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 e ISAM podrían almacenar registros de longitud fija o variable, y todos los tipos podrían ocupar más de un volumen de disco.
Todos estos se basan en la estructura del disco VTOC .
Los primeros sistemas de gestión de bases de datos de IBM utilizaban varias combinaciones de conjuntos de datos ISAM y BDAM, normalmente 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:
Estos formatos VSAM se convirtieron en la base de los sistemas de gestión de bases de datos de IBM , IMS/VS y DB2 , normalmente ESDS para el almacenamiento de datos propiamente dicho y KSDS para los índices.
VSAM también incluyó un componente de catálogo utilizado para catálogos de usuarios y el catálogo maestro de MVS.
Los conjuntos de datos particionados (PDS) son conjuntos de datos secuenciales subdivididos en "miembros" que podrían procesarse cada uno como archivos secuenciales por derecho propio (como una carpeta en un sistema de archivos). El uso más importante de los PDS era para las bibliotecas de programas: los administradores del sistema utilizaban 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 son bibliotecas de procedimientos de control de trabajos (PROC) de uso frecuente y "libros de copia" de declaraciones de lenguajes de programación, como definiciones de registros utilizadas 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 mediante un número de generación absoluto o mediante un desplazamiento de la generación más reciente. Originalmente fueron diseñados para admitir procedimientos de copia de seguridad abuelo-padre-hijo : si se modificaba un archivo, la versión modificada se convertía en el nuevo "hijo", el "hijo" anterior se convertía en el "padre", el "padre" anterior se convertía en el "abuelo". " y se eliminó el "abuelo" anterior. Pero se podrían configurar GDG con más de 3 generaciones y algunas aplicaciones usaban GDG para recopilar datos de varias fuentes y alimentar la información a un programa: cada programa recopilador creaba una nueva generación del archivo y el programa final leía todo el grupo como un archivo secuencial único (al no 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 funciones para integrarlos parcialmente. Es decir, los programas Unix que usan 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 nuevo (que no debe confundirse con el ZFS de Sun ) utiliza datos lineales VSAM. Establecer (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 VSAM orientados a registros mediante el uso de productos cliente-servidor implementados de acuerdo con la Arquitectura de administración de datos distribuida (DDM). ). DDM es también la arquitectura base para el servidor MVS DB2 que implementa la arquitectura de base de datos relacional distribuida (DRDA).
MVS incluye una función llamada E/S virtual (VIO), con la que se pueden almacenar conjuntos de datos temporales en pistas simuladas en los conjuntos de datos de paginación, lo que elimina la sobrecarga de asignación pero agrega cierta sobrecarga de procesamiento.
Además de la nueva funcionalidad que IBM agregó con las versiones y subversiones de OS/VS2, IBM proporcionó varias versiones de cambios incrementales (ICR) y unidades seleccionables (SU) gratuitas y productos de programas con cargo y programas desarrollados en el campo que IBM finalmente incluyó como parte de z/OS. Éstas incluyen:
A finales de los setenta y principios de los ochenta, IBM anunció:
DF/DS agregó soporte para nuevos dispositivos e IBM anunció que ya no agregaría soporte para dispositivos a la base gratuita. DF/EF agregó la estructura de catálogo mejorada (ICF) como alternativa a los catálogos VSAM y los volúmenes de control (CVOL), pero estaba plagada de problemas de confiabilidad.
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 serían retirados. de marketing, a partir del 1 de diciembre de 1984. DFP/370 Versión 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 el producto MVS/Extended Architecture Data Facility (5665-284) era un correquisito para MVS/SP versión 2 (MVS/XA). Además de mejorar las funciones de gestión de datos, DFP reemplazó las versiones gratuitas del editor de enlaces y las utilidades.
DFP ya no está disponible como un producto independiente, sino que ha pasado a formar parte del subsistema de gestión de almacenamiento de instalaciones de datos , con el nombre DFSMSdfp .
MVS ahora ha evolucionado a z/OS; IBM ya no admite versiones anteriores de MVS y, desde 2007, solo se admiten 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. [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 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 bajo MVS/370 reciben cada uno 16 MB de almacenamiento virtual contiguo.
MVS/XA , o Almacenamiento Virtual Múltiple/Arquitectura Extendida , era una versión de MVS que soportaba la arquitectura 370-XA , que tenía una nueva arquitectura de E/S y también direcciones ampliadas de 24 bits a 31 bits, proporcionando una memoria direccionable de 2 gigabytes . área. [9] MVS/XA admitía un modo de direccionamiento heredado de 24 bits para aplicaciones de 24 bits más antiguas (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 Enterprise System Architecture ( MVS/ESA ) es cualquier versión de MVS anterior a OS/390 que admita S/370 Enterprise Systems Architecture (S/370-ESA). MVS/ESA amplía los modos de direccionamiento de 24 y 31 bits de MVS/XA agregando 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 Lanzamiento 3 de MVS/ESA SP anunciada [15] de 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 superiores 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 (Almacenamiento administrado por sistema de instalación de datos). 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 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 funciones abiertas se convirtieron en una parte estándar de Vanilla MVS/ESA SP Versión 5 Lanzamiento 1, IBM dejó de distinguir OpenEdition del sistema operativo. Bajo OS/390 V2R6 se convirtió en UNIX System Services , [19] [20] y mantuvo ese nombre bajo z/OS .
A finales de 1995, IBM incluyó MVS con varios productos de programas y cambió el nombre de MVS/ESA a OS/390.
El nivel actual de MVS se comercializa como z/OS.
Los fabricantes japoneses de mainframes Fujitsu e Hitachi obtuvieron repetida e ilegalmente el código fuente MVS y la documentación interna de IBM en uno de los casos de espionaje industrial más famosos del siglo XX . [21] Fujitsu dependió en gran medida del código de IBM en su sistema operativo 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 poseen 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 ortográficos y los errores de documentación de IBM fueron copiados fielmente. IBM cooperó con la Oficina Federal de Investigaciones de EE. UU. en una operación encubierta , suministrando a Fujitsu y Hitachi, a regañadientes, MVS patentadas y tecnologías de hardware de mainframe 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 . Cualquier comunicación de Amdahl a Fujitsu se realizó a través de "Especificaciones exclusivas de Amdahl" que fueron escrupulosamente limpias de cualquier propiedad intelectual de IBM o cualquier referencia a la propiedad intelectual de IBM.
Después de las investigaciones, IBM llegó a acuerdos multimillonarios tanto con Fujitsu como con Hitachi, recaudando fracciones sustanciales de las ganancias de ambas compañías durante muchos años. Informes fiables indican que los acuerdos superaron los 500.000.000 de dólares estadounidenses. [ cita necesaria ] [21] [NB 7]
Hace tiempo que las tres empresas acordaron amistosamente numerosas empresas comerciales conjuntas. Por ejemplo, en 2000 IBM y 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 externos con productos compatibles con MVS pudieron producir versiones compatibles con MSP y VOS3 con poca o ninguna modificación. [22] [23] [24]
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 y Hitachi optaron por no otorgar licencias de z/Architecture de IBM para sus sistemas operativos y sistemas de hardware cuasi-MVS, por lo que MSP y VOS3, aunque todavía son nominalmente respaldados por 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 todavía admite aplicaciones y tecnologías de la era MVS (z/OS todavía contiene la mayor parte del código de MVS, aunque muy mejorado durante décadas de evolución), las aplicaciones (y procedimientos operativos) que se ejecutan en MSP y VOS3 pueden migrar a z/OS. mucho más fácilmente que a otros sistemas operativos.
Servicios del sistema UNIX
Nombre cambiado de OpenEdition a OS/390 UNIX System Services
{{cite book}}: |work=ignorado ( ayuda )