Multiple Virtual Storage , más comúnmente llamado MVS , es el sistema operativo más utilizado en los mainframes 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 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 se extendió
En un principio, IBM describió a MVS como una simple nueva versión de OS/VS2 , pero en realidad se trata de una reescritura importante. La versión 1 de OS/VS2 es una actualización de OS/360 MVT que conserva la mayor parte del código original y, al igual que MVT, está escrita principalmente en lenguaje ensamblador . El núcleo de MVS está escrito casi en su totalidad en ensamblador XF , aunque algunos módulos se escribieron en PL/S , pero no los sensibles al rendimiento, en particular no el Supervisor de entrada/salida (IOS). El uso de "OS/VS2" por parte de IBM enfatizaba la compatibilidad ascendente: los programas de aplicación que se ejecutaban bajo MVT ni siquiera necesitaban volver a compilarse para ejecutarse bajo MVS. Los mismos archivos de 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 llamaron al nuevo sistema MVS casi unánimemente 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 (Multiprogramming with a Fixed Number of Tasks) [1] ofrece 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 desocupe la partición grande. OS/360 R19 agregó subtareas MFT ( multitarea ), la capacidad de un trabajo para crear dinámicamente nuevas tareas con la macro ATTACH.
OS/360 MVT (Multiprogramming with a Variable number of Tasks) [1] 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 asigna memoria a regiones para los pasos de 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 ordenació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 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 pequeños trozos 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 (a la que IBM llamó "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 ú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. Por lo tanto, OS/VS1 y SVS en principio tenían las mismas desventajas que MFT y MVT, pero los impactos son menos graves 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 salí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 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, esencialmente con la misma lógica de entrada y salida de intercambio que TSO en MVT.
A mediados de la década de 1970, IBM introdujo MVS, que no sólo admitía un almacenamiento virtual mayor que el almacenamiento real disponible, [NB 2] como lo hacía SVS, sino que también permitía ejecutar una cantidad indefinida de aplicaciones en diferentes espacios de direcciones. Dos programas simultáneos 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 hizo que MVS fuera la solución perfecta para los problemas comerciales que surgían de la necesidad de ejecutar más aplicaciones.
MVS maximiza el potencial de procesamiento al proporcionar capacidades de multiprogramación y multiprocesamiento . [2] Al igual que sus predecesores MVT y OS/VS2 SVS , MVS admite 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 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 de sistemas operativos IBM en admitir configuraciones multiprocesador , aunque la variante M65MP de OS/360 que se ejecutaba en los modelos 65 y 67 de 360 había proporcionado un soporte multiprocesador limitado. El modelo 67 de 360 también había alojado 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 [ aclaración necesaria ] potencia de procesamiento que los sistemas 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 acoplados de forma flexible, lo que significa que cada computadora tiene acceso a una carga de trabajo común, o acoplados de forma estrecha , lo que significa que las computadoras comparten el mismo almacenamiento real y están controladas por una sola copia del sistema operativo . [ aclaración necesaria ] MVS mantuvo tanto el multiprocesamiento acoplado de forma flexible de Attached Support Processor (ASP) [NB 3] como el multiprocesamiento acoplado de forma estrecha de OS/360 Model 65 Multiprocessing . En los sistemas acoplados de forma estrecha, dos CPU compartían acceso concurrente a la misma memoria (y copia del sistema operativo) y periféricos, lo que proporcionaba mayor potencia de procesamiento y un grado de degradación elegante si una CPU fallaba. En las configuraciones acopladas de forma flexible, cada uno de un grupo de procesadores (únicos y/o acoplados de forma estrecha) tenía su propia memoria y sistema operativo, pero compartía periféricos y el componente de sistema operativo JES3 permitía gestionar 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 a través de discos compartidos y adaptadores de canal a canal (CTCA). Esta capacidad finalmente estuvo disponible para los usuarios de JES2 como Multi-Access SPOOL (MAS). [ cita requerida ]
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) direccionamiento 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 se ejecutaban en un único espacio de direcciones, y el sistema de administración de bases de datos relacionales DB2 necesitaba más de 8 MB de espacio de direcciones de aplicación para ejecutarse de manera eficiente. (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 de MVS son: Job Control Language (JCL), que fue diseñado originalmente para procesamiento por lotes pero desde los años 1970 en adelante también se utilizó para iniciar y asignar recursos a trabajos interactivos de larga ejecución como CICS ; y TSO (Time Sharing Option), la interfaz interactiva de tiempo compartido , que se utilizó principalmente para ejecutar herramientas de desarrollo y algunos sistemas de información de usuario final. ISPF es una aplicación 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 de una manera 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 se agregaron funciones, como ISPF , más tarde para interfaces controladas por formularios. [3]
MVS dio un gran paso adelante en la tolerancia a fallos, basándose 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. Los fallos del sistema ahora tenían grandes impactos en los negocios de los clientes, e IBM decidió dar un gran salto de diseño, asumir que a pesar de las mejores técnicas de desarrollo y prueba de software, "los problemas SÍ ocurrirán". Esta profunda suposición fue fundamental para agregar grandes porcentajes de código de tolerancia a fallos al sistema y probablemente contribuyó al éxito del sistema en tolerar fallos 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 ha mejorado, en muchas dimensiones, estas características de recuperación de software tolerante a fallos y resolución rápida de problemas con el tiempo.
Este diseño especificaba una jerarquía de programas de manejo de errores, en modo de sistema (núcleo/'privilegiado'), denominados Rutinas de Recuperación Funcional, y en modo de 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, procesador o almacenamiento, o error de software). Cada rutina de recuperación hacía que la función 'principal' fuera reinvocable, capturaba datos de diagnóstico de errores suficientes para depurar el problema causante y, o bien la 'reintentaba' (reinvocaba la función principal) o bien la 'filtraba' (escalaba el procesamiento de errores a la siguiente rutina de recuperación en la jerarquía).
De esta forma, 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 podía pasar era que se eliminara un espacio de direcciones de usuario (un "trabajo") en caso de errores no reparados. Aunque 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 tenía garantizada su propia rutina de recuperación, sino que ahora cada rutina de recuperación tiene su propia rutina de recuperación. Esta estructura de recuperación estaba incorporada en el programa de control básico de MVS, y los desarrolladores de programas de aplicación y de terceros tienen a su disposición y utilizan las funciones de programación.
En la práctica, la recuperación de software de 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 (tanto en modo de tarea como de sistema) hagan esto.
IBM incluyó criterios adicionales para los problemas de software importantes que requerían de su servicio. Si un componente principal no lograba iniciar la recuperación del software, se consideraba que se trataba de un fallo notificable válido. Además, si una rutina de recuperación no lograba recopilar datos de diagnóstico significativos de modo que el problema original pudiera resolverse con los datos recopilados por esa rutina de recuperación, las normas de IBM dictaban que esa falla era notificable y requería reparación. Por lo tanto, las normas de IBM, cuando se aplicaban rigurosamente, fomentaban la mejora continua.
IBM siguió dando soporte a la importante herramienta de mantenimiento Dynamic Support System [4] (DSS) que había introducido en OS/VS1 y OS/VS2 Release 1. Esta función interactiva podía invocarse para iniciar una sesión con el fin de crear procedimientos de diagnóstico o invocar procedimientos ya almacenados. Los procedimientos capturaban eventos especiales, como la carga de un programa, la E/S de un dispositivo o las llamadas a procedimientos del sistema, y luego activaban los procedimientos definidos previamente. Estos procedimientos, que podían invocarse de forma recursiva, permitían leer y escribir datos y alterar el flujo de instrucciones. Se utilizó hardware de grabación de eventos de programa.
IBM dejó de brindar soporte para DSS con Selectable Unit 7 (SU7), una actualización de OS/VS2 Release 3.7 requerida por el producto de programa OS/VS2 MVS/System Extensions (MVS/SE), número de programa 5740-XEl. El grupo de usuarios SHARE aprobó un requerimiento para que IBM restableciera DSS, e IBM proporcionó un PTF para permitir el uso de DSS después de que se instalara MVS/SE.
IBM volvió a abandonar el soporte para DSS con SU64, una actualización de OS/VS2 Release 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 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 dicha máquina 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 inusualmente altos. Como resultado de mejoras posteriores del hardware, una instancia de un sistema operativo (ya sea MVS, VM con invitados u otro) también podía ocupar una partición lógica (LPAR) en lugar de un sistema físico completo.
Se pueden organizar y administrar de forma colectiva varias instancias de MVS en una estructura denominada complejo de sistemas o sysplex , introducido en septiembre de 1990. Las instancias interoperan a través de un componente de software denominado Cross-system Coupling Facility (XCF) y un componente de hardware denominado Hardware Coupling Facility (CF o Integrated Coupling Facility, ICF, si se encuentran ubicados 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) patentada 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 ha obtenido la certificación UNIX 95 para z/OS V1R2 y posteriores. [5]
El sistema se utiliza normalmente en empresas y bancos, 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 sentencias EXEC CICS con el código COBOL apropiado para llamar a CICS antes de que se compile el programa, no muy diferente de 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 lenguaje se empaqueta como un componente común llamado "Entorno de lenguaje" o "LE" para permitir una depuración uniforme, seguimiento, creación de perfiles y otras funciones independientes del lenguaje.
Tradicionalmente, se accede a los sistemas MVS mediante terminales 3270 o PC que ejecutan emuladores 3270. Sin embargo, muchas aplicaciones mainframe en la actualidad tienen interfaces web o GUI personalizadas . El sistema operativo z/OS tiene soporte integrado para TCP/IP . La administración del sistema, que antes se hacía con un terminal 3270, ahora se realiza a través de la consola de administración de hardware (HMC) y, cada vez más, de 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 a él.
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, un 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 las páginas de código de origen y destino como entradas.
En MVS , los archivos que no son de Unix se denominan conjuntos de datos . Los nombres de esos archivos se organizan en catálogos que son archivos VSAM .
Los nombres de los conjuntos de datos (DSN, término de mainframe para los nombres de archivos) se organizan en una jerarquía cuyos niveles están separados por puntos, p. ej., "DEPT01.SYSTEM01.FILE01". Cada nivel de la jerarquía puede tener hasta ocho caracteres de longitud. 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 los archivos de forma similar a los directorios de otros sistemas operativos. Por ejemplo, hay programas de utilidad que realizan funciones similares a las del Explorador de Windows (pero sin la interfaz gráfica de usuario y, por lo general, 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 solo 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 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, análogos 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 e ISAM podrían almacenar registros de longitud fija o de longitud 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 real y KSDS para los índices).
VSAM también incluye 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 como archivos secuenciales por derecho propio (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 usaban el PDS principal como una forma de asignar espacio en disco a un proyecto y luego 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 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 el mismo nombre, a los que se puede hacer referencia por número de generación absoluto o por un desplazamiento desde la generación más reciente. Originalmente, se diseñaron 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 el "abuelo" anterior se eliminaba. Pero se podían configurar GDG con más de 3 generaciones y algunas aplicaciones usaban GDG para recopilar datos de varias fuentes y enviar la información a un programa: cada programa de recopilación creaba una nueva generación del archivo y el programa final leía todo el grupo como un solo archivo secuencial (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 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 [NB 5] restricciones. 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 más nuevo (zFS) (que no debe confundirse con el ZFS de Sun ) utiliza un conjunto de datos lineales VSAM (LDS).
Los programas que se ejecutan en computadoras conectadas en red (como IBM AS/400 ) pueden utilizar interfaces de administración de datos locales para crear, administrar y acceder de manera transparente a archivos orientados a registros VSAM mediante productos cliente-servidor implementados de acuerdo con la Arquitectura de administración de datos distribuidos (DDM). DDM también es 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, eliminando la sobrecarga de asignación pero agregando cierta sobrecarga de procesamiento.
Además de las nuevas funciones que IBM agregó con las versiones y subversiones de OS/VS2, IBM proporcionó una serie de versiones de cambio incremental (ICR) y unidades seleccionables (SU) gratuitas, así como productos de programas con cargo y programas desarrollados en campo que IBM finalmente incluyó como parte de z/OS. Entre ellos se incluyen:
A finales de los años 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 plagado 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 se retirarían de la comercialización a partir del 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 facilidades de administración de datos, DFP reemplazó las versiones gratuitas del editor de enlaces y las utilidades.
DFP ya no está disponible como un producto separado, sino que se ha convertido en parte del Subsistema de gestión de almacenamiento de instalaciones de datos , bajo 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 más antiguas de 24 y 31 bits junto con aplicaciones más nuevas de 64 bits.
Las versiones de MVS hasta 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 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, 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 soportaba la arquitectura 370-XA , que 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 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).
La arquitectura de sistemas empresariales MVS ( MVS/ESA ) es cualquier versión de MVS anterior a OS/390 que admita 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 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 fines de 1995 y posteriormente con z/OS .
MVS/ESA OpenEdition: actualización a la versión 4 Se anunció la versión 3 de MVS/ESA SP [15] en 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 de 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 . Los especialistas independientes estiman que era compatible con sistemas abiertos en más del 80%, más que la mayoría de los sistemas Unix. El soporte de 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 la versión 5 Release 1 de MVS/ESA SP, 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 combinó MVS con varios productos de programación 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 repetidamente e ilegalmente el código fuente MVS de IBM y la documentación interna en uno de los casos más famosos del siglo XX de espionaje industrial . [21] Fujitsu dependió en gran medida del código de IBM en su sistema operativo de mainframe MSP , y del mismo modo Hitachi hizo lo mismo para su sistema operativo VOS3. MSP y VOS3 se comercializaron intensamente en Japón, donde aún tienen una parte sustancial de la base instalada de mainframes, pero también en cierto grado en otros países, especialmente Australia. Incluso los errores y errores ortográficos de la documentación de IBM fueron copiados fielmente. IBM cooperó con la Oficina Federal de Investigaciones de los EE. UU. en una operación encubierta , suministrando de mala gana 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 funcionarios del gobierno japonés. Sin embargo, Amdahl no estuvo involucrado 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", que fueron escrupulosamente limpiadas de cualquier propiedad intelectual de IBM o de cualquier referencia a la propiedad intelectual de IBM.
Tras las investigaciones, IBM llegó a acuerdos multimillonarios con Fujitsu y Hitachi, y durante muchos años cobró una parte sustancial de las ganancias de ambas empresas. Según informes fiables, los acuerdos superaron los 500 millones de dólares estadounidenses. [ cita requerida ] [21] [NB 7]
Las tres empresas acordaron hace tiempo de manera amistosa iniciar numerosas operaciones 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 de terceros 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, 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 z/Architecture de IBM para sus sistemas operativos y sistemas de hardware cuasi-MVS, por lo que MSP y VOS3, aunque siguen recibiendo soporte nominal de 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 mejorado y mejorado en gran medida 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 mucho más fácilmente que a otros sistemas operativos.
Servicios del sistema UNIX
Se cambió el nombre de OpenEdition a OS/390 UNIX System Services