En verano de 1970, IBM amplió el juego de instrucciones e implementó el mecanismo de memoria virtual del 360/67 en todos los modelos, y por consiguiente, desarrollando y adaptando los SO existentes para trabajar con memoria virtual, rebautizando la nueva arquitectura como IBM S/370. A partir de aquí, a lo largo de los años 70 y 80, las máquinas se hicieron más grandes en tamaño, potencia, velocidad y recursos, pero la arquitectura básica de 1964 no cambió en absoluto.
Por un lado venía de puta madre, porque los programas escritos en 1964 funcionaban perfectamente en 1980, pero a toda leche. Pero por otro, dado que el bus de direcciones era de 24 bits, y los programas eran cada vez mayores, se dieron cuenta que al final existía una limitación hardware de 16 MB de RAM direccionable, tanto real como virtual. Así que IBM se puso manos a la obra, y en 1982 desarrollo la arquitectura S/370-XA, que tenía un bus de 32 bits, lo que hacía que se direccionala hasta ¿4 GB de RAM? Noooo! Sólo podía direccionar 2 GB de RAM.
Y a que se debe esto? Pues muy sencillo: Como para IBM primaba la compatibilidad hacia atrás, se las arreglo para que a nivel hardware los programas escritos para 24 bits no notaran la diferencia, usando de los 32 bits, un bit (el 31) para decir si la página de memoria esta por encima de los 16 bits (XA) o esta por debajo (tradicional). Así, mi programa escrito en 1964 funcionaría por debajo de los 16 MB como siempre, pero los nuevos programas que escriba a partir de ahora, podría desarrollarlos a 31 bits y situarlos en un espacio de direcciones por encima de los 16 MB. O que coño, puedo coger mis fuentes y recompilarlos con mi compilador y decirle que me los sitúe encima de los 16 MB de RAM (solo tengo que poner un parámetro en el compilador).
Como información adicional, esa diferencia entre menos de 16 MB y mas de 16 MB la denominó “La LINEA”, haciendo referencia a que por debajo de la línea, se situaban los programas tradicionales, y por encima de la línea, los programas “cool” nuevecitos. Y ya que estamos, IBM en 1988 le dio por desarrollar un nuevo concepto de memoria virtual: Los múltiples espacios de almacenamiento, haciendo referencia a que cada programa podría tener su propia gestión de la memoria virtual, por capas, desterrando así el concepto de gestión plana de memoria. A esta arquitectura, se la denomino IBM ESA/370 (Enterprise Systems Architecture).
En la década de los 90, IBM desarrolló una nueva arquitectura llamada ES/9000, multiprocesadores con múltiples espacios de memoria, sistema LPAR de particiones virtuales de máquina (vamos, VMwares por hardware), cambiando el nombre de la arquitectura ESA/370 a ESA/390. Fue también la época donde se desterró el cobre como medio de transmisión y se impuso la fibra óptica (ESCON –Enterprise Systems CONnection), por lo que el acceso a discos, cintas, etc, se realizaba vía fibra a velocidades de 20 MB/seg por canal, mientras que en cobre como mucho se podían alcanzar velocidades de 4,5 MB/seg (decir que puedes conectar mas de un canal a un periférico, así que el ancho de banda se balancea automáticamente y lo multiplicas).
A partir de ese momento, y una vez que en 1994 los ES/9000 estaban en pleno auge, IBM cambió la tecnología a una más barata, pequeña pero mucho mas veloz, llamada IBM Parallell Enterprise Server, sacando cada año, una generación (desde la G1 hasta el G6 de 1999).
Pero fue en el año 2000 cuando IBM dijo: 2 GB me saben a poco. Quiero más. Así que desarrolló la arquitectura z/Series, con un espacio de direcciones de 64 bits, lo que hacía que podría direccionar hasta 16 EXABYTES de datos en memoria. Es decir, que en el último z/Series que me compre mañana mismo, me va a funcionar un programa escrito en 1964. Te cagas.
No existe otro sistema informático en el mundo que respete de forma tan fiel la compatibilidad hacia atrás. Como nota curiosa, como el bit 31 es el identificador que sitúa a un programa por encima o por debajo de la línea, hay 2 GB que no se pueden direccionar, para la máquina no existen. Así que a estos 2 GB “fantasmas” se les denomino La BARRA.
Por encima de la Barra, y al igual que pasaba con la línea, puedo compilar un programa y hacer que se ejecute o debajo de la línea, o entre la línea y la barra o por encima de la barra, ya os digo que cambiando un parámetro.
Después de este “breve” paso por los adelantos tecnológicos que ha sufrido la historia del mainframe, paso ya a comentar los adelantos de los SO de la época hasta nuestros días.
A lo largo de la vida de la plataforma S/360, se desarrollaron los siguientes SO:
DOS para las máquinas pequeñas
OS/360 para las máquinas medianas/grandes
TSS/360 para sistemas de tiempo compartido y multiusuarios.
Pero como el TSS/360 fue un fiasco mayúsculo, fue reemplazado por los siguientes productos:
CP/67, que luego pasaría a llamarse VM/370
TSO, Time Sharing Option, para OS/360
A continuación, paso a explicar brevemente cada uno:
DOS: Disk Operating System, ideado para máquinas pequeñas. Se almacenaba en disco y ocupaba 24 KB. Existía tambien una versión tipo Knoppix “Live-Tape” llamada TOS, para equipos que no tenían disco duro y se cargaba todo desde cinta.
Este SO sólo podía ejecutar una tarea a la vez, así que era como podréis observar similar al MS-DOS, pero con 25 años de diferencia. Vamos, que Microsoft no inventó absolutamente nada. Tenía un espacio de direcciones plano así que si tu programa no cabía en memoria real, pues a joderse.
Se introducía en programa por tarjetas y daba un resultado. Simple a mas no poder –por eso no petaba, a menos que tu, como programador lo metieras en un bucle infinito por tu ineptitud picando código-, y como esto se parece mucho al MS-DOS, pues poco mas que añadir.
TSS/360: Este SO quería ser algo mejor de lo que hacía el Multics de aquel entonces. Como IBM sabía que el impacto iba a ser sobrecogedor, empleo a miles y miles de programadores en todo el mundo para hacer el TSS/360. Lo que tenía este SO de bueno era que podías tener cientos de terminales simultáneamente trabajando contra la misma máquina, cada uno desarrollando programas, ejecutándolos, en definitiva, interactuando con la máquina en tiempo real.
El resultado fue un pedazo de mierda solo comparable con MS Windows 95 Primera edición: tardaba 10 minutos arrancar, hasta que te aparecía el LOGON, y luego tenías 10 minutos de vida aproximadamente hasta que se cayera todo el sistema de manera dramática. Evidentemente, IBM abandonó dicho proyecto y nunca se llegó a comercializar.
TSO: No obstante, cuando murió el TSS, algunos desarrolladores de IBM se quedaron con la copla y con lo mejor del TSS y desarrollaron un nuevo sistema de tiempo compartido, llamado TSO (Time Sharing Option), que ha perdurado hasta nuestros días (si veis una pantalla verde en algún ministerio o ayuntamiento con emulación 3270, o es que hay un CICS (un gestor transaccional desarrollado en 1968) o hay TSO, no puede haber nada más).
El problema es que por aquel entonces, no funcionaba tan maravillosamente, ya que el TSO comía más de media máquina en MFT o MVT (luego los explico), sin contar con el hecho que una vez al día por lo menos, cascaba estrepitosamente.
CP67: Este SO virtualizaba en todos los aspectos la máquina real, dando la sensación que el usuario tenía toda una máquina S/360 para el solito, pero al final todo es un programa, como el de Parada. Se llama Control Program.
Por consiguiente, podías instalar un SO dentro de esa máquina, ya sea MVT, MFT, DOS o lo que quisieras, al igual que lo hace un VMware de los de hoy en día. Al final, este SO se rebautizó como VM/370 con la llegada del System/370. Y ha seguido una evolución tecnológica de acuerdo a la tecnología existente, pasando de ser VM/370 a VM/370-XA, VM/ESA, y ahora, z/VM.
OS/360: El estandarte de los sistemas operativos de la época y el que mas recursos humanos en todo el mundo ha tenido –antes de la llegada de GNU/Linux-. Robusto de narices, es EL SO mas seguro del mundo. El nombre de OS/360 viene a que ese iba a ser el SO que iba a soportar toda la gama de máquinas, pero al principio se desarrollaron varias fases:
OS/360-PCP: Primary Control Program: Era una parte muy muy simple del OS/360, y como el DOS, solo podía ejecutar un programa a la vez. Pero claro, OS/360-PCP necesitaba de un maquinón para su ejecución, así que la gente que se decantaba por una máquina pequeña y un sistema operativo similar, se iba de cabeza al DOS. Así que este SO se quedo en los laboratorios de IBM para desarrollar software para otros SO.
OS/360-MFT: Multiprogramming with Fixed number of Tasks: Meses mas tarde, salió a la luz y fue el primer SO multitarea de la historia. La memoria la dividías en regiones y cada región podía ejecutar un programa distinto. Pero la pega es que debías conocer al dedillo los jobs o programas que ibas a lanzar, ya que si un job ocupaba más que la región seleccionada, no cabía y por lo tanto, no podía ser ejecutado.
Y si tenias que cambiar la configuración de las regiones de memoria, tenías que apagar todo y volver a configurar, por lo que era un modelo chungo de trabajo, aunque si te lo montabas bien, podrías ejecutar cientos de tareas simultáneas.
OS/360-MVT: Multiprogramming with Variable number of Tasks: Este SO podía crear y borrar regiones de memoria a placer, de tal forma que para ejecutar un job, el SO miraba la memoria disponible y consultaba la cola de jobs por si alguna le entraba en ese espacio libre y si lo encontraba, creaba la región que iba a consumir el job y luego lo cargaba para su ejecución.
La ventaja es evidente, ya que el sistema se reconfigura automáticamente de acuerdo a las necesidades de tu job, pero esto traía una desventaja con los jobs que consumían poca memoria pero que requerían de mucho tiempo de CPU para finalizar, y era que al de un rato de tener la máquina funcionando, estos jobs se situaban en una zona central de la memoria, y que el espacio libre de memoria de alrededor no se podía aprovechar porque los otros jobs que están esperando en la cola no entraban en esas partes libres, así que no podrían entrar hasta que estos pequeños jobs terminaran y se liberase dicha memoria, creando cuellos de botella y paradas de exclusiones mútuas si un job en ejecución necesitara que otro job se ejecutara para terminar.
Por lo tanto, se desarrolló un producto llamado HASP que no era mas que un planificador de trabajos, que ordenaba la cola de jobs de acuerdo a sus consumos de memoria y demás parámetros, y saliendo en un orden predefinido mediante unas hebras o “slots” predefinidos. Esta ejecución se parece mas a MFT, pero con la ventaja de la reordenación de la memoria que realiza el HASP (que con el paso de los años se rebautizaría como JES –Job Entry Subsystem-).
Cuando el hardware de memoria virtual estuvo disponible en los modelos posteriores, los diversos SOs se rebautizaron. Al OS/360-MFT se llamó OS/VS1 y al OS/360-MVT se le llamó OS/VS2. Además se re-escribieron ya que con la memoria virtual, dejaba de ser necesario que el programa adquiriera la memoria contigua, con lo que el problema del MVT sin el HASP desaparecía (aunque se siguió utilizando el HASP –JES2- igualmente). Sucesivas ampliaciones del OS/VS2 y con el hardware que admitía múltiples espacios de direcciones virtuales, lo rebautizaron como MVS (Multiple Virtual Storage).
Con la llegada de la arquitectura 370 se le llamó MVS/370, luego con la XA se le llamo MVS/XA, luego MVS/ESA, y ya con el cambio de nombre de la arquitectura a S/390, se volvió a utilizar el OS/360 para llamarlo OS/390. Y en el 2000, con el z/Series, z/OS. Pero vamos, en la practica el z/OS se basa en los mismos fundamentos que el OS/360 pero con las mejoras tecnológicas. Existe el concepto de submitir jobs, el JES2, el TSO, etc.
A partir de aquí, hay toda una gama de productos para el buen desempeño de la máquina: El SDSF (Spool Display and Search Facility) que administra el JES2 y todos los trabajos, colas, etc. El RMF (Resource Measuremente Facility) que monitoriza usando los registros del SMF (System Management Facility) el estado de la máquina, productos como DFSMS (Data Facility Storage Management System) que ordena los datos en disco según ciertas políticas, el DFSMS-hsm (Hierachical Storage Manager) que migra datos poco usados a cintas, etc.
Y luego productos como DB2 para bases de datos, CICS para el transaccional, herramientas de programación y desarrollo en Cobol, C, Java, así como herramientas de orientación a la web tipo Lotus Domino+Notes, Websphere, así como OMVS (Openedition MVS, un UNIX embebido dentro del SO), etc. Y eso sin contar con los monitores de rendimiento de cada producto que instales, por ejemplo el TMON o el OmegaMon del CICS, y demás utilidades de Boole& Babagge de monitorización, a no ser que te guste mas el Tivoli Netview.
Y eso es todo amigos. Si queréis alguna información adicional, Internet es el camino, sobre todo los ABC’s Of System Programming z/OS que IBM publica en PDF con descarga directa desde mi web.
No obstante, se podría montar un buen foro de opinión sobre esto, ya que ya he recibido mensajes de los que apoyan esta arquitectura y los que la rechazan. Y creedme, es muy interesante conocer opiniones de todos los ámbitos
