DOS/360 y sucesores

El Sistema Operativo Básico (BOS) fue una versión temprana de DOS y TOS que podía proporcionar funcionalidad utilizable en un sistema con tan solo 8  KB de almacenamiento principal y una unidad de disco 2311. ^{[ 3 ]}

TOS/360 (Tape Operating System/360, que no es un DOS propiamente dicho ni se denomina así) fue un sistema operativo de IBM para el System/360 , utilizado en sus inicios, alrededor de 1965, para dar soporte al System/360 Modelo 30 y plataformas similares.

TOS, como indica la palabra "Tape" en su nombre, requería una unidad de cinta. Compartía la mayor parte del código fuente ^{[ 4 ]} y algunos manuales ^{[ 5 ] [ 6 ]} con DOS/360 de IBM.

TOS tuvo 14 versiones y se descontinuó ^{[ 7 ]} cuando discos como el IBM 2311 y el IBM 2314 se volvieron más asequibles en la época del System/360, ^{[ 8 ]} mientras que habían sido un lujo caro en el IBM 7090 .

DOS/360 era el sistema operativo principal para la mayoría de las instalaciones S/360 de tamaño pequeño a mediano.

DOS/VS se lanzó en 1972. La primera versión de DOS/VS se denominó "Versión 28" para indicar una actualización incremental de DOS/360. ^{[ 9 ]} Añadió memoria virtual para dar soporte al nuevo hardware de la serie System/370 . Utilizaba una tabla de páginas fija que asignaba un único espacio de direcciones de hasta 16 megabytes para todas las particiones combinadas.

DOS/VS aumentó el número de particiones (programas simultáneos separados) de tres (denominadas Background, Foreground 1 y Foreground 2) a cinco (BG y F1 a F4) y permitió un total de quince subtareas en todo el sistema. ^{[ 10 ] : pp.24–28}

DOS/VS fue sucedido por DOS/VSE a través de z/VSE .

DOS/VSE se introdujo en 1979 como una versión "extendida" de DOS/VS para dar soporte a los nuevos procesadores 4300. ^{[ 11 ]} Los sistemas 4300 incluían una función llamada ECPS:VSE que proporcionaba almacenamiento de un solo nivel tanto para el procesador como para los canales de E/S. ^{[ 12 ]} DOS/VSE ofrecía soporte para ECPS:VSE, pero también podía ejecutarse en un System/370 sin esa función. VSE fue la última versión gratuita de DOS.

VSE/Advanced Functions ^{[ 13 ]} (VSE/AF), preparado para su entrega en 1983, agregó compatibilidad con nuevos dispositivos y funcionalidad a DOS/VSE. Muchas instalaciones ejecutaron VSE/AF utilizando productos como VSE System Installation Productivity Option/Extended (VSE System IPO/E), que combinaba DOS/VSE, VSE/AF y otros productos.

SSX/VSE ("Small System Executive") fue un intento de IBM de simplificar la compra e instalación de VSE al proporcionar un sistema pregenerado que contenía el sistema operativo y los productos más populares. ^{[ 14 ]} SSX se lanzó en 1982, ^{[ 15 ]} y posteriormente fue reemplazado por VSE/SP. IBM vendió SSX como un paquete de 14 productos componentes (Advanced Functions/VSE, VSE/POWER, ACF/VTAME, VSE/VSAM, CICS/DOS/VS, DOS/VS, Sort/Merge, VSE/ICCF, VSE/OCCF, VSE/IPCS, DOS/COBOL, Back Up/Restore, Space Management, VSE/DITTO), y originalmente solo aceptaba ofrecer los productos individuales por separado a través de RPQ , aunque IBM posteriormente accedió a agregar esos productos individualmente a su lista de precios bajo la presión de los ISV que alegaban que el paquete violaba las leyes antimonopolio. ^{[ 16 ]}

En 1986, IBM lanzó VSE/SP ("System Product") junto con el anuncio de los procesadores 9370. VSE/SP reemplazó a SSX/VSE e incluyó VSE con los productos de programa VSE más populares, como VSE/AF, ACF/VTAM , CICS y POWER/VS . ^{[ 17 ]} VSE/SP solo admitía direcciones de 24 bits, a pesar de las solicitudes de los clientes para que se proporcionara una versión XA (31 bits).

VSE/ESA era una versión de DOS/VSE de 31 bits, lanzada en 1990 con soporte para hasta 384  MB de almacenamiento real. Proporcionaba hasta doce particiones estáticas y permitía que VSE/POWER y ACF/VTAM se ejecutaran en espacios de direcciones privados . Introdujo una nueva característica llamada particiones dinámicas que podía permitir hasta 150 trabajos concurrentes, cada uno en su propio espacio de direcciones. ^{[ 18 ]} La versión 1 podía ejecutarse en modo ESA o 370, y el modo ESA también admitía hardware XA con limitaciones. La versión 2 (1995) solo admitía el modo ESA con hardware ESA. La versión 2 añadió soporte para multiprocesamiento , a través del nuevo Turbo Dispatcher , que permite que diferentes particiones se ejecuten simultáneamente en diferentes procesadores. Una partición solo puede ejecutarse en un procesador a la vez, lo que limita principalmente el multiprocesamiento a la multitarea . Teóricamente se admiten hasta diez procesadores ("tolerados"), pero efectivamente se utilizan hasta cuatro. ^{[ 19 ] [ 20 ]} Esos límites permanecen en el último z/VSE. ^{[ 21 ]}

IBM lanzó z/VSE 3.1 en 2005. Este cambio de nombre reflejó la nueva marca "System z" para la línea de productos mainframe de IBM, pero no representó un cambio fundamental en la arquitectura con respecto a VSE/ESA 2.7, que lo precedió. En particular, no era compatible con la nueva arquitectura z/Architecture de 64 bits, y solo funcionaba en modo de 31 bits incluso en máquinas compatibles con 64 bits. z/VSE 4.1, lanzado en 2007, introdujo la compatibilidad con direccionamiento real de 64 bits, con hasta 8  GB de memoria. Sin embargo, aunque partes del supervisor funcionan en modo de 64 bits, solo proporciona espacios de direcciones virtuales de 31 bits a las aplicaciones de estado de problemas. En 2011, una estimación situó el número de sitios que utilizaban z/VSE en alrededor de 4000. ^{[ 22 ]}

En junio de 2021, 21st Century Software Inc. anunció que había obtenido la licencia del código fuente de z/VSE de IBM con la intención de desarrollar nuevas versiones del sistema operativo. ^{[ 23 ]} Como parte de esta transferencia, z/VSE pasó a llamarse VSE ⁿ . ^{[ 24 ] [ 25 ]}

El concepto de área transitoria forma parte de la discusión de Mythical Man-Month sobre el diseño y el uso de la memoria principal. ^{[ 27 ]} Para reducir aún más el uso de memoria, el supervisor empleó superposiciones llamadas transitorias que se leían en una de las dos áreas transitorias reservadas según fuera necesario.

• Los transitorios físicos se cargaron en el área A-Transient de 556 bytes para manejar errores de hardware (ERP), registrar datos específicos de errores (OBR/MDR) en IJSYSRC y emitir mensajes de error. Todos los nombres de los módulos A-Transient comenzaban con $$A .
• Los transitorios lógicos se cargaron en el área B-Transient de 1200 bytes para proporcionar servicios de programa comunes como OPEN y CLOSE para LIOCS. Todos los nombres de los módulos B-Transient comenzaban con $$B .

El uso de los prefijos $$A y $$B garantizó una carga rápida de los transitorios porque sus nombres se almacenaban primero en el directorio.

DOS/VS añadió controladores de comprobación de máquina y de canal, que eran otro conjunto de transitorios que comenzaban con $$RAST y se ejecutaban en el área de transitorios de recuperación. Esto se hizo como parte de las mejoras de fiabilidad, disponibilidad y facilidad de mantenimiento (RAS) para el System/370 . Antes de esta adición, las comprobaciones de máquina provocaban la terminación del programa en ejecución y las comprobaciones de canal provocaban la terminación del programa que accedía al dispositivo, en el momento del error.

Al igual que OS/360 , las versiones iniciales de DOS solo podían ejecutar un programa a la vez. Las versiones posteriores del "verdadero" DOS podían ejecutar hasta tres programas simultáneamente, en particiones de memoria separadas, con el apoyo de las mismas características de protección de memoria de hardware del sistema operativo OS/360, más escalable. Estas se identificaron como BG ( fondo ), F1 ( primer plano  1 ) y F2 ( primer plano  2 ). La multiprogramación era una característica opcional de DOS/360, seleccionable en la generación del sistema . ^{[ 26 ] : p.34} Una opción posterior de SYSGEN permitía la ejecución de operaciones por lotes en cualquiera de las particiones FG. De lo contrario, los programas en primer plano debían ser iniciados manualmente por el operador de la computadora .

DOS/VS permitía hasta siete programas concurrentes, aunque cinco o seis era un número más común debido a la menor escala del hardware que solía albergar los sistemas DOS. Tanto DOS como DOS/VS permiten configurar el número de particiones durante la carga inicial del programa ( IPL , por sus siglas en inglés), término que utiliza IBM para referirse al arranque del sistema.

Los programas ejecutables se almacenaban en una Biblioteca de Imagen Central (CIL) . Durante su ejecución, DOS no podía liberar espacio a medida que los programas se eliminaban o reemplazaban por versiones más recientes. Cuando la CIL se llenaba, debía comprimirse mediante un programa de utilidad, lo que podía interrumpir el desarrollo hasta su finalización. Muchas empresas simplemente congelaban los cambios durante un día, comprimían la CIL fuera de línea e iniciaban el sistema con la nueva CIL al comienzo de la jornada laboral. También se admitía una biblioteca reubicable para programas objeto enlazables y una biblioteca de sentencias fuente para macros de ensamblador y texto de inclusión. Las instalaciones podían definir bibliotecas reubicables y de sentencias fuente privadas adicionales en otros volúmenes de disco.

DOS/360 contaba con un conjunto de programas de utilidad , un ensamblador y compiladores para FORTRAN , COBOL y, finalmente, PL/I , y admitía una variedad de organizaciones de archivos con métodos de acceso para facilitar su uso:

• Los conjuntos de datos secuenciales solo se leían o escribían, un bloque de registros a la vez, de principio a fin.
• En los archivos indexados ( ISAM ), se definía una sección específica de cada registro como una clave que podía utilizarse para buscar registros específicos.
• En los archivos de acceso directo ( BDAM ), el programa de aplicación debía especificar la ubicación física en el disco de los datos a los que quería acceder. La programación BDAM no era sencilla y la mayoría de los clientes nunca la utilizaban; sin embargo, era la forma más rápida de acceder a los datos en los discos y muchas empresas de software la empleaban en sus productos, especialmente en sistemas de gestión de bases de datos como ADABAS , IDMS y DBOMP y DL/I de IBM .

Los archivos 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.

DOS/360 ofrecía el Método Básico de Acceso a Telecomunicaciones ( BTAM ) y el Método de Acceso a Telecomunicaciones en Cola ( QTAM ). BTAM era primitivo y difícil de usar según los estándares posteriores, pero permitía la comunicación con casi cualquier tipo de terminal, lo que representaba una gran ventaja en una época en la que existía poca estandarización de los protocolos de comunicación. La simplicidad de su API también facilitaba la interfaz con procesadores de comunicaciones externos, lo que permitió que las máquinas DOS/360 se convirtieran en nodos de las redes de múltiples niveles de las grandes organizaciones. Por otro lado, los usuarios de QTAM no necesitaban tanto conocimiento sobre los dispositivos individuales, ya que QTAM operaba a nivel lógico mediante las macros OPEN/CLOSE/GET/PUT.

El JCL de DOS fue diseñado para ofrecer velocidad y simplicidad en el análisis sintáctico; la sintaxis posicional resultante era significativamente más críptica que el control de trabajos basado en palabras clave de OS/360.

Las primeras versiones de DOS no incluían un subsistema de cola de impresión para mejorar la eficiencia de las entradas/salidas de las impresoras de tarjetas perforadas y de línea . A finales de la década de 1960, tanto IBM como los proveedores externos comenzaron a cubrir esta necesidad. El gestor de cola de impresión de IBM era una opción llamada Priority Output Writers, Execution processors and input Readers (POWER) , y Software Design, Inc., una empresa de software independiente, vendía un gestor de cola de impresión llamado GRASP .

DOS/360 no tenía un cargador reubicable , por lo que los programadores tenían que editar el enlace para crear una versión ejecutable independiente de cada programa para cada partición o espacio de direcciones en el que probablemente se ejecutaría. Como alternativa, los programas en lenguaje ensamblador podían escribirse como auto-reubicables , pero esto imponía una complejidad adicional y un aumento de tamaño, aunque pequeño. Las grandes empresas que utilizaban DOS, con múltiples máquinas y múltiples diseños de particiones, solían escribir su propio cargador reubicable para sortear este problema.

La interfaz de programación de aplicaciones (API) de DOS/360 era incompatible con OS/360. Los programas escritos en lenguajes de alto nivel para DOS debían compilarse y enlazarse antes de poder usarse con OS/360. Las pequeñas diferencias entre los compiladores de DOS y OS a veces requerían modificaciones en los programas. Sin embargo, la migración en sentido contrario era más compleja. Dado que OS/360 admitía muchas más funciones en su API, cualquier uso de dichas funciones debía eliminarse de los programas que se portaban a DOS. Esto suponía un problema menor para los programadores que trabajaban con lenguajes de alto nivel como COBOL . Los programas en lenguaje ensamblador , por otro lado, solían utilizar esas mismas funciones con mayor frecuencia y, por lo general, requerían mayores modificaciones para ejecutarse en DOS.