Para explicar un poco el tema, antes hay que comentar también el tipo de Hardware que había en esa época para entender mejor ciertas decisiones de diseño que se tomaron.

Como dije en ocasiones anteriores, hasta Abril de 1964 cada computador era de un padre y una madre distintos. Esto hacia que estas computadoras “bastardas” requiriesen un nivel de especialización importante, y tanto sus programas como datos tenían obligatoriamente que estar adaptados a esas maquinas. Pero a partir de esa fecha, IBM creo el S/360 (360 hace referencia a los 360 grados de una circunferencia, dando a entender que podría adaptarse a todo el rango de opciones habidas y por haber).

Esta máquina constaba de varios modelos, desde el modelo 20 que tenía 64 raquíticos KBs de RAM (pero en aquella época era como tener 4 GB en tu PC), hasta el modelo 91, que era el ordenador mas potente de la gama que se instaló en el sistema de defensa de misiles nucleares de los EEUU, en plena guerra fría. A pesar de sus diferencias en potencia, tenían el mismo juego de instrucciones, solo que en el modelo pequeño muchas instrucciones las tenía en microcódigo mas que en hardware propiamente dicho (por ejemplo, mientras que en el modelo 91 la multiplicación estaba implementada por hardware, en el modelo 20 era una macroinstrucción que sumaba n veces).

Se desarrollaron una serie de sistemas operativos, de acuerdo a la potencia de cada maquina. Mientras que las mas cutres y salchicheras no tenían SO y que lo único que hacían era leer de tarjetas perforadas y generar nuevos datos en tarjetas o impresoras, las máquinas de gama media con una cierta potencia, se instalaban con una versión de DOS (se lo que pensáis y no oiga, que no, de MS-DOS nada ) y las de gama alta, con un sistema operativo llamado OS/360. DOS era un sistema operativo que solo podia ejecutar una tarea a la vez (que no, coño, que no es MS-DOS), y mientras esa tarea se ejecutaba, solo cabía esperar a que la finalizara. En cambio, OS/360 era… bueno, de esto hablaremos largo y tendido…

Pero al tema: En Abril de 1964 se hizo pública la noticia del desarrollo del IBM S/360, pero no fue hasta un año mas tarde cuando se comercializó el modelo de mas baja gama. Al modelo 20 le siguieron modelos 40, etc, hasta que en junio de 1966 salió el modelo 67, el primero que tenía soporte hardware para la memoria virtual. Tenia un DAT (Dynamic Address Translation) y una lógica de paginación de memoria, por lo que a partir de ese momento, podrías ejecutar cualquier programa del espacio de direcciones dado a pesar de no tener la suficiente memoria real. IBM planeo el perfecto Sistema Operativo que explotara todas las capacidades de esta máquina, llamado TSS/360, pero lamentablemente no lo hicieron funcionar lo suficientemente bien como para comercializarlo con la cabeza bien alta ya que se petaba cada dos por tres (es decir, que tuvieron mas vergüenza que Microsoft y su Windows con pantallas azules). Luego lo explicaré mas detalladamente…

No obstante, IBM también desarrollo otro sistema operativo para ese modelo, llamado CP-67, que permitía la virtualización de varias máquinas en una sola, dando la sensación a cada usuario que tenia toda la máquina para el solito. Además, podía emular otro tipo de máquinas, por lo que este SO vino de perlas para desarrolladores de software de esta y otras plataformas distintas.

AVANCES HARDWARE

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 -Customer Interface Control System, un gestor transaccional desarrollado en 1968- o hay TSO, no puede haber nada mas). 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.

Tradicionalmente, los mainframes han tenido una gran variedad de periféricos, según la tecnología de la época. Así pues, en los albores de la época, lo más común eran los dispositivos electro-mecánicos, utilizando tarjetas de cartón como soporte para el almacenamiento de la información.

Este tipo de tarjetas se perforaban y de ese modo, cada perforación marcaba un bit, que era 0 o 1 en función de si esta zona de la tarjeta se perforaba o no. Cada tarjeta representaba una línea de código, por lo que un programa tenía una cantidad importante de tarjetas que debían ir en secuencia, para cargar el programa en memoria. Luego, a petición del programa, se cargaban otra secuencia de tarjetas que representaban los datos que ese programa iba a utilizar.

¿Sabías por que el modo texto de las pantallas y las impresoras matriciales normales tipo A4, tienen 80 columnas? Porque esos eran los caracteres que podía llevar una tarjeta perforada. De hecho, llevaba 9 filas que marcaban 8 bits + un bit de paridad, y luego, 80 columnas.

¿Y sabéis por que una tarjeta perforada tenía 80 columnas? Porque la tarjeta perforada de ordenador se basó en el tipo de tarjetas perforadas que llevaban las máquinas de tejer de aquel entonces, que utilizaban 80 hilos para hacer motivos decorativos y encajes en las telas.

Pero al grano: Las tarjetas se introducían en una máquina lectora (READER) que era la que estaba conectada al procesador mediante unos cables de bus. Cuando la totalidad de las tarjetas se leían, se enviaba una señal al procesador para avisar de que el programa ya había sido leído y que por lo tanto podía comenzar su ejecución.

El procesador, por lo tanto, adquiría el control y ejecutaba el programa, pidiendo que se introdujeran las tarjetas perforadas de los datos a tratar y su resultado lo dejaba o en una impresora, o en una maquina perforadora de tarjetas (PUNCH) con los datos modificados. Hasta que el programa no terminaba, no se podía hacer nada mas que aguantar el estrepitoso ruido de las maquinas lectoras y perforadoras.

De ahí viene el sistema de proceso por lotes o BATCH, es decir, la ejecución repetitiva de programas que tratan una gran cantidad de datos, en este caso miles y miles de tarjetas. Cabe decir que los procesos tardaban muchísimo dada la complejidad mecánica de las maquinas de tarjetas perforadas, y sobre todo si el volumen de datos era inmenso, pero si ese tiempo se comparaba con el trabajo manual de la época, era todo un record.

Fue, con la llegada de la cinta magnética en 1953 por parte e IBM, cuando el panorama informático dio un salto de gigante en la rapidez y ejecución. Se basaba en una tira de plástico a la que se le había pintado un recubrimiento ferruginoso, de modo que si se imantaba cierta parte con una polaridad, se quedaba imantada para siempre. Os podréis entonces imaginar como se diferenciaba un 1 de un 0 con este método, ¿no?

Los carretes de cinta magnética empezaron a sustituir poco a poco a las maquinas de lectura/perforación de tarjetas. La estructura era bien simple: en una cinta de media pulgada de ancho, cabían en fila india a lo ancho, 9 bits (8 bits del carácter y el bit de paridad, como con las tarjetas perforadas).

Y a lo largo, en una pulgada podían entrar, según la densidad, 700, 1600, 3000 o 6250 bits. Vamos, que en 2,5 centímetros, entraba lo equivalente a 78 tarjetas perforadas puestas en fila a lo largo. Como esos carretes podían guardar 3600 pies de cinta enrollada, pues te puedes imaginar el salto cualitativo que producía eso, además de que la velocidad de proceso se multiplico por 100 ya que la cinta magnética era muy rápida, a razón de 600 KB/seg -las de alta gama llegaban a 1 MB/seg, un record en aquella época-.

En ese trajín de añadir a todo una capa magnética, en 1957, un ingeniero de IBM se le ocurrió que si forraba unos platos de sustrato magnético, los ensartaba en un eje central y añadía un cabezal que se movía desde el exterior al interior del plato, podría leer cualquier información almacenada en cualquier lugar de esos platos en vez de tener que esperar a que una cinta magnética bobinara el carrete hasta llegar a ese dato concreto.

Se inventó pues el primer disco magnético de la historia, el RAMAC 650, por lo que los programas y datos se podían almacenar en un dispositivo que permitía el acceso directo y por lo tanto, mucho mas rápido que la cinta magnética, cuyo acceso como ya he dicho era secuencial y había que recorrer toda la cinta hasta recuperar el dato. Estos discos podían almacenar hasta 5 MB de datos, que para 1957, era una cantidad ingente de información.

Pero no fue el fin de las unidades de cinta. La razón era bien sencilla: Adquirir una unidad de disco costaba como 50 unidades de cinta, y por si fuera poco, cada carrete de cinta podía almacenar mas información que el propio disco, y encima cada carrete virgen costaba dos duros.

Por lo tanto, se creó el modelo de datos por niveles: Los datos de mayor acceso se almacenaban en disco, ese preciado aparato, y los datos que no se utilizaban tan a menudo, se guardaban en cinta (por ejemplo, históricos, dumps, logs, etc): Por lo tanto, lejos de extinguirse, fueron evolucionando, logrando mayor rapidez y densidades, hasta que en 1980 se introdujo por primera vez el sistema de cartuchos. La cinta estaba dentro de un cartucho de plástico, que se introducía en un cargador automático, con lo que el tiempo de montaje de una cinta de carrete se reducía a la mitad, y eso sin contar con los fallos de lectura que solían dar las tradicionales cintas de carrete y el mantenimiento y limpieza que debían tener.

Los primeros cartuchos (3480) podían almacenar 200 MB distribuidos en 18 pistas (no 9 con las cintas en carrete) dentro de un cartucho que ocupaba la 4ª parte que un carrete de cinta de 3600 pies. Además, estas unidades por primera vez incorporaron una lógica hardware similar al algoritmo ZIP llamada IDRC (Improved Data Recording Capability) que duplicaba o triplicaba la capacidad de almacenamiento dependiendo de los datos que almacenaba (y os puedo asegurar que el juego de caracteres EBCDIC se comprime que da gusto, mucho más incluso que el ASCII).

La evolución de 3480 fue el 3490, que podía almacenar 400 MB (800 con IDRC) y disponía de 36 pistas, 18 en un sentido y 18 en sentido contrario. Esto hacía que los cartuchos no se tendrían que rebobinar, ya que cuando llegaba al fin de la bobina y había escrito 18 pistas, el cabezal se movía 0,5 milímetros y seguía escribiendo 18 pistas en sentido contrario hasta que se rebobinaba el cartucho. Este sistema se perfeccionó con cartuchos de mayor densidad (800 MB, 1,2 GB) y ya en los 90, con 128 pistas, y 20 GB de capacidad nativa, las unidades 3590.

Actualmente las unidades de cinta de mainframe son de cartucho de 200 GB de capacidad, y en estos momentos se están comercializando unidades de 800 GB y 1,6 TB por cartucho, vamos, una sobrada, ya que cada cartucho de estos no llega a costar 60 euros, es con mucho el coste por gigabyte mas barato de la historia de la informática.

Pero volvamos a los años 60: aunque luego podías utilizar la cinta o los discos para grabar los datos, seguía haciendo falta algo para introducir programas la primera vez, por lo que seguía haciendo falta una tropa de gente que perforaba a mano las tarjetas. Hasta que apareció la consola.

La consola fue en sus principios, un teletipo, y mientras escribías en un teclado de maquina de escribir, te iba imprimiendo en papel lo que ibas haciendo (algo similar a las maquinas de escribir) y a la vez, se iba almacenando en memoria. Años mas tarde, en los 70, con la tecnología CRT, se inventó el terminal y en el se pudo visualizar lo que se escribía en vez de gastar tanto papel, y se creo la capacidad de edición y demás utilidades que facilitaron enormemente el trabajo de los programadores.

A partir de ese momento, surgieron numerosos dispositivos periféricos como unidades de comunicaciones de todo tipo, como modems, subsistemas de telecomunicación, terminales, impresoras, cintas, discos, lectores ópticos, robots, etc.
Estructura interna e interconexión de un mainframe

Un mainframe es grande. Es MUY grande, si lo comparamos con un PC, y visualmente aún hoy ocupan varios metros cuadrados con forma de armarios roperos puestos seguidos uno al lado del otro y de color negro. En el caso del mueble principal (de ahí viene lo de “main frame”) esta compuesto por varios módulos interconectados entre sí, formando un CPC (Central Processor Complex):

* MCM: Multi-Chip-Module: Viene a ser la CPU de un PC, y tiene su memoria cache interna, como en los PCs, solo que en este caso tiene muchas CPUs, de ahí lo de Multi-Chip.
* Main Storage: O lo que es lo mismo, la RAM de la máquina.
* Channel Subsystem: Es un modulo con varias CPUs que se encargan de gestionar el sistema de I/O entre el procesador y los dispositivos.

Este modulo esta compuesto también de varias tarjetas de I/O, que pueden ser conectores de cable tradicional paralelo con velocidades de 4,5 MB/seg, o la evolución de dichos conectores en forma de fibra óptica, que pueden variar entre los 20 MB/seg (ESCON) y los 4 Gb/Seg (FICON).

A estos canales se les conectan todos y cada uno de los dispositivos periféricos. También existen tarjetas de comunicaciones y de red, pero son evoluciones de la tecnología (en los años 80, una “tarjeta” de red Ethernet era como un frigorífico de grande, aunque el conector era RJ-45 o BNC).

El resto de armarios que ocupan el Centro de Proceso de datos son los periféricos. Estos periféricos, solían tener por lo menos 2 armarios: uno de ellos era la Unidad de Control y otro, el dispositivo periférico en sí (por ejemplo, la unidad de control de discos 3880 y las unidades de disco 3380).

Actualmente y por la disminución de los componentes electrónicos, es habitual que la unidad de control y el periférico estén dentro del mismo armario. La unidad de control es el sistema que está conectado directamente ente el mainframe y el dispositivo, y tiene su propio Sistema Operativo en forma de firmware o microcódigo que le da una cierta “inteligencia” a la hora de interpretar las ordenes que recibe del procesador central.

Un ejemplo puede ser el del uso eficiente de los discos: Si el mainframe le pide un dato concreto a un disco, la unidad de control recibe la instrucción y busca la manera mas fácil de dárselo, por ejemplo evaluando los caminos de fibra que tiene y decidiendo por que camino llevarlo, guardando ese dato y los siguientes en su cache, por si el mainframe pidiera el siguiente dato, etc.

Estas unidades de control también hacen las veces de buffer de datos y proporcionan un eficiente sistema de control de errores, además de que en caso de fallo de hardware, estas unidades se las arreglan para evitar la perdida de datos, porque tienen en todo momento los caminos duplicados para lograr redundancia.

Sin más, en otro tocho explicaré la evolución de los Sistemas Operativos de estas máquinas, y como el ámbito PC ha copiado toda la tecnología.