A principios de los ochenta aproveché una buena oferta y salté a otro Banco Nacional.
El cambio supuso una mejora económica (pequeña) y un nuevo y apasionante proyecto.
El ordenador de este nuevo Banco (nuevo para mí, quiero decir) era un IBM 3081 nuevecito, con dos procesadores (¡nada menos!) y 16 Mb de memoria.
IBM 3081. Principio de los ochenta.
O sea, un gran mainframe de IBM, de lo más que había en la época (casi casi lo único que había como ordenador central). Este ordenador era evolución de la serie IBM 303x, que a su vez lo era del mítico IBM 370, que había sustituido en los primeros setenta al no menos mítico IBM 360.
Su Sistema Operativo era MVS, y tenía Bases de Datos IMS (DL/1) y gestor de teleproceso IMS/DC, ambos recién estrenados, y que iban a dar servicio al nuevo Sistema Integrado Online de dicho Banco (que había que construir desde cero, claro. Cuando yo decía que era un proyecto apasionante, no exageraba ni lo más mínimo…).
Se programaba en Cobol (salvo ciertos módulos de Sistema, que se escribían en Assembler), es decir, todo el software de Aplicación estaba programado en Cobol. Es más, en estos tiempos (que yo sepa) sigue programado en Cobol. Y, en una buena parte, siguen siendo los mismos programas, remozados, cambiados, modernizados… pero los mismos.
El método de trabajo en estas máquinas ya no era el mismo que el que seguíamos en el otro Banco, con su Century 200, según os conté en esta entrada. Entraré más en detalles de la forma de trabajar en la época dentro de un par de episodios, si es que os sigue interesando.
Y sí, es cierto que en aquella entrada os prometía hablaros en la de hoy de dos cosas: de los grandes mainframes de IBM, y del lenguaje Cobol. Pero ya sabéis los que me seguís que, cuando empiezo a escribir, no sé parar, así que la entrada me ha salido tan larga, que he pensado que sería mejor para vuestra salud mental, queridos lectores, dividirla en dos partes.
En ésta veremos sólo los mainframes, y en la próxima me centraré en el lenguaje Cobol, con un añadido (un “bonus track“, al más puro estilo de la industria del vídeo) para hablar, desde mi experiencia, del “Problema del Año 2000″, también conocido como “El Virus del Milenio”.
Los grandes mainframes actuales de IBM (sucesores de aquellos cacharros), programados casi todos en Cobol, siguen siendo las piezas básicas que mantienen al mundo en movimiento. Por ello, voy a dedicar este artículo describir sucintamente a estas máquinas, las grandes desconocidas de la mayoría de la población, e incluso de la mayoría de informáticos de nuevo cuño, que piensan que un servidor Linux de gran potencia es lo más de lo más… y no por su culpa: es lo que han visto, oído, leído, y les han enseñado durante toda su vida.
Si este artículo contribuye a que conozcan un poco más a estas bestias pardas, habrá cumplido su función. Por ello, no sólo voy a describir los mainframes de los años 80, sino también los de hoy en día.
Veréis que esto no es tan extraño como parece: aunque con potencia infinitamente superior, los z/Series de hoy se parecen mucho, de cara a sus programadores y usuarios, al venerable IBM/370 de hace casi cuarenta años.
IBM 370. Años setenta.
Entonces, lo primero que hay que mencionar es la estabilidad de esta gama de ordenadores. Se han producido, y se siguen produciendo, gigantescos avances en ellos igual que en el resto de ramas de la informática, pero, al estar todos ellos sin excepción dedicados a operaciones críticas, la estabilidad es la primera máxima de diseño. Eso quiere decir, por ejemplo, que un programa escrito y compilado en los años setenta sigue funcionando hoy en día en los ordenadores actuales… ¡sin necesidad siquiera de compilarse de nuevo con cada cambio de versión!.
El código máquina de estos ordenadores es hoy el mismo que hace cuarenta años. Naturalmente, los procesadores son muchíiisimo más complejos ahora, hay muchos más códigos de instrucción para hacer cosas cada vez más sofisticadas… pero los códigos originales se mantienen. Es decir, hay una compatibilidad hacia delante que, simplemente, no existe en ninguna otra gama de ordenador, de la marca que sea.
Los mainframes actuales se denominan IBM z/Series, y no son más que la evolución de los 360, 370, 303x, 308x, 3090, 390, etc. En esta entrada tenéis a vuestra disposición TODA la información que deseéis sobre cómo es y cómo funcionan estos Sistemas: El “IBM z/Architecture Principles of Operation“, de estudio obligado para todo Técnico de Sistemas de estos ordenadores.
IBM 360. Años 60. Con ellos empezó todo...
La principal diferencia es, además de su potencia, varios órdenes de magnitud superior, el tamaño: el 3081 con que operaba aquél banco, más todo sus dispositivos (discos, cintas magnéticas, impresoras, unidades de comunicaciones, etc) atestaba él solito la Sala de Ordenadores entera, con sus doscientos cincuenta o trescientos metros cuadrados… y ahora en ese espacio cabrían decenas de mainframes.
Son máquinas realmente potentes (los datos que cito a continuación son del z10Ec, el más potente de los actuales mainframes de IBM):
- Hasta 64 procesadores de alta capacidad por ordenador. Son procesadores de cuatro núcleos a 4,4 Ghz de reloj. Esto significa un ciclo de reloj de 0,22 nanosegundos, es decir, 220 picosegundos. Con una configuración “normal”, de 16 ó 24 procesadores (en España no creo que haya ningún mainframe con 64), es capaz de procesar algunos miles de MIPS (Millones de Instrucciones por Segundo: Millones reales (y verificables) de Instrucciones cada Segundo, no Millones teóricos, que es lo que se acostumbra a medir en otros Sistemas.
- Hasta 1,5 Tb de memoria de alta velocidad (eso es Mucha memoria…).
- Hasta 1024 Canales de Entrada/Salida. Son canales de Alta Capacidad y velocidades de transferencia muy elevadas, de varios Gb por segundo.
Foto y diagrama del Z/Series z10EC
Y sin embargo, viendo las características físicas no parece tan potente, comparado con máquinas especializadas de procesamiento en paralelo, como la propia “Blue Gene” de IBM, que tienen miles y miles de procesadores. Y es que la diferencia está en su Software.
Su Sistema Operativo por excelencia es, hablando con propiedad, el único Sistema Operativo que existe (se trata del antiguo MVS, que tras varios cambios de nombre ahora se llama z/OS; IBM ofrecía también por aquella época, en los años 70 y 80, el DOS/VSE, igual que ahora también ofrece Linux para z/Series, ignoro con qué éxito comercial).
Cuando se enumeran las funciones y características que, teóricamente, debe tener todo Sistema Operativo, sólo MVS (perdón, z/OS; es que todos los que hemos trabajado con él le seguimos llamando “MVS”) cumple todas ellas. Por ejemplo:
1- Disponibilidad total. IBM dice en su marketing que tiene un 99,999% de disponibilidad, y no sólo es cierto, sino que yo creo que es un 100%. De hecho, los mainframes de IBM sólo suelen apagarse una vez al año (generalmente en Navidades, Viernes Santo, o así), más bien por el prurito de hacer un Arranque en Frío al menos una vez al año (o sea, apagar y encender, vaya) y así limpiar la memoria de posibles zonas muertas, que porque haga realmente falta.
2- Independencia del Sistema Operativo de las Aplicaciones (incluso las propias del Sistema). Es decir, absolutamente todos los productos, sean cuales fueren, se pueden instalar en caliente, sin necesidad de apagar y encender nada. Esto reza incluso para el propio Sistema Operativo: se puede subir de versión sin necesidad de pararlo. Y desde luego, para todos los productos, por críticos que resulten: IMS, CICS, DB2, RACF, VTAM, etc. Y, por descontado, el MVS (perdón otra vez, el z/OS, la costumbre…) no se cae nunca. Al menos, yo no lo he visto en años.
3- Absoluta garantía de que una partición no puede acceder a datos de otra, ni por error, ni a posta. Además, no hay virus (al menos, que yo conozca) para mainframes: la seguridad es máxima.
4- Capacidad de configurar varias máquinas lógicas (particiones) dentro de una única máquina física. Con ello se puede trabajar como si tuviéramos tres o cuatro máquinas diferentes, más pequeñas, pero que se comportan a todos los efectos como si fueran máquinas físicas diferentes. Además, la partición se realiza no distribuyendo partes físicas de la máquina (canales o procesadores, por ejemplo) sino por MIPS. Podemos definir una máquina de 150 MIPS, otra de 400 MIPS y otra de 700 MIPS, por ejemplo. Y, naturalmente, se puede reconfigurar los tamaños de cada partición en cualquier momento… y sin parar nada, claro.
5- Rendimiento combinado inalcanzable para cualquier otra máquina. Por ejemplo, un mainframe típico (no el más grande, repito) es capaz de dar servicio él solo a:
- 500 ó 600 trabajos batch (en la jerga “mainframera”, iniciadores), donde se están ejecutando trabajos batch: liquidaciones, extractos de cuentas, abonos de dividendo, tareas de backup, pruebas de programas, etc, todo lo que no necesite hacerse online. No 500 ó 600 al día, no. 500 ó 600 a la vez, continuamente, todo el día sin parar, todo el año sin parar.
- Varios gestores de teleproceso diferentes (IMS ó CICS), sirviendo cada uno algunos millones de transacciones online diarias. Para que os hagáis una idea: un Banco nacional típico puede tener quizá diez o quince millones de transacciones online diarias, una operadora de Telecomunicaciones, quizá registre 80 millones de llamadas diarias, etc: se procesa online muchísima información hoy en día. ¿Os hacéis una idea de la tasa de transacciones por segundo que supone esta carga?… 200, 300, 400 transacciones por segundo, cada segundo, todos los segundos. Son realmente muchas. Estas transacciones, habitualmente subsegundo, pueden ser servidas por uno sólo de estos gestores, por ejemplo, un IMS. Y suele haber otros gestores de Teleproceso dedicados a otras cosas, como la Contabilidad, los Seguros, etc.
- Varios centenares de particiones de time-sharing, el famoso TSO, (donde cada usuario ve la máquina como si fuera literalmente para él solo). Por ejemplo, programadores editando y compilando programas, usuarios finales lanzando peticiones de información, operadores gestionando el sistema, etc. Con tiempos de respuesta generalmente subsegundo también.
- …SIMULTÁNEAMENTE. Es decir, todo lo anterior, a la vez. Un mainframe de IBM está habitualmente usando su CPU (todas ellas) al 100%. Horas y horas, días y días, meses y meses, sin parar. Es normal verlo incluso al 102% (cosa aparentemente imposible, debida al prefetch de instrucciones, que permite ganar algo de tiempo al solapar la ejecución de instrucciones consecutivas). Y no pasa nada. Muchos otros sistemas operativos, al llegar al 80% de uso de CPU comienzan a dar señales de lentitud. Y a partir del 90%, se vuelven inestables. El z/OS, no. Es más, casi todos los que trabajamos normalmente con ellos “sabemos” que cuando están a menos del 90%, están “vagos”, como si les costara más de lo normal despachar los diferentes trabajos… Vale, ya lo sé, es una sensación que no tiene base alguna, pero es que la tenemos mucha gente…
Aunque son sistemas muy fiables por su diseño, también en los mainframes se producen errores y roturas de hardware, como es natural. Con 12 o 16 procesadores que funcionan día y noche, es posible que, por muy fiables que sean, tarde o temprano uno de ellos falle y tenga que ser reemplazado, y lo mismo ocurre con el resto de componentes: memoria, discos magnéticos, unidades de comunicaciones, etc.
Data Center Sun StorageTek. Hasta 200 Tb de capacidad
Imaginemos, por ejemplo, una moderna instalación, que puede tener del orden de 150 Tb de espacio en disco disponible (no sólo se necesita para guardar la información permanente, sino para espacio de trabajo, copias, etc). Dependiendo de en qué momento se fueron incorporando los diferentes discos a la instalación, estos tendrán una tecnología u otra, girarán más o menos rápido, y su capacidad individual estará más o menos entre 50 y 500 Gb. Supongamos una media de 150 Gb por disco, lo que puede ser una cifra bastante real.
Pues bien, en esta instalación prototipo, sólo discos de mainframe hay unos 1.000, más o menos antiguos, girando 24 horas diarias a un mínimo de 7200 vueltas por minuto. Supongamos también que estos discos tienen un MTBF (Tiempo Medio Entre Fallos, una medida de la fiabilidad de un componente) de 200.000 horas, que no está nada mal. O sea, si tenemos un solo disco, podemos esperar, si tenemos suerte, que falle de media cada 200.000 horas, que son… ¡veintitrés años! Pero es que… ¡tenemos 1.000 discos, o más! Sin hacer muchas cuentas complicadas, podemos darnos cuenta de que en realidad podemos esperar un fallo de un disco individual cada quizá 150 ó 200 horas, o sea, tendremos un disco roto cada par de semanas o así. Y puede fallar cualquiera, desde el menos importante, que sólo sirva como espacio de trabajo, al propio disco donde se encuentra el Sistema Operativo.
Pues… la instalación no puede pararse por un disco roto, sea cual sea el que se rompa; y lo mismo si lo que falla es cualquier otro componente, por crítico que sea.
En los mainframes es poco menos que imposible encontrar un componente aislado cuya rotura origine una parada total del sistema, y toda sustitución de un elemento hardware estropeado se realiza sin necesidad de parar el resto de los componentes (ni los iguales, ni otros distintos) ni, desde luego, el Sistema Operativo, que simplemente marcará ese dispositivo como inutilizable mientras dure la avería, y volverá a utilizarlo cuando ésta se subsane. Aunque no es propiamente un Sistema “Fault Tolerant“, se trata de un sistema realmente fiable.
Producción Industrial
En fin, la gran mayoría de grandes Cajas y Bancos, los diferentes Organismos de la Administración (Hacienda, Trabajo y Seguridad Social, Interior, etc), las grandes compañías industriales y comerciales, sobre todo las que llevan bastantes años en el mercado, casi todas ellas continúan usando mainframes de IBM para sus Operaciones, y que yo sepa, ninguna tiene la menor intención de cambiar a otro tipo de máquinas.
Porque, además, resulta un Sistema muy barato de administrar. Con una veintena de Técnicos de Sistemas (muy bien pagados, eso sí) se puede gestionar el parque de mainframes de una gran empresa… cuando con toda seguridad la misma empresa necesitaría cientos de ellos para administrar un Sistema de Información similar basado en, por ejemplo, UNIX.
Ojo, no me malinterpretéis, yo no he dicho que un mainframe de IBM sea una máquina barata: en absoluto lo es. Su coste es muy superior, sobre el papel, al de un Sistema UNIX o Linux equivalente, y no digamos Windows… Agravado por el hecho de que los programas imprescindibles (Sistema, Base de Datos, Gestor de Teleproceso, Gestor de Seguridad…) IBM no los vende, sino que son alquilados: no se adquiere una licencia permanente de uso (la que permite utilizar de por vida el producto mientras no se actualice… y mientras siga funcionando, claro), sino sólo el derecho a usar el software durante un cierto tiempo, generalmente un año, incluyendo el mantenimiento, nuevas versiones, solución de problemas, etc. Y no se trata de productos baratos, precisamente.
Pero si nuestra empresa no se puede arriesgar a que una simple actualización de, digamos, el software de la impresora, te deje frita la Aplicación de Cuentas Corrientes, o la Aplicación de Pedidos… es la mejor opción. Además, como dije, no se conocen virus para z/OS. No digo que no los haya, sino que de momento no se conocen, así que la seguridad ante intrusiones es máxima. Esto es debido a que, por su arquitectura interna, es bastante difícil que un hacker pueda encontrar una vulnerabilidad expotable en el Sistema. ¡Y a que ya nadie enseña Ensamblador del z/Series!, exceptuando a la propia IBM, que cobra una fortuna por ello.
Y recordad, Aplicaciones escritas en los años 80 (cuando no había prácticamente ninguna alternativa importante a los mainframes de IBM) siguen funcionando hoy en día sin problemas, incluso sin siquiera compilar de nuevo los programas, lo que les otorga un Retorno de la Inversión realmente elevado.
…Y no, no trabajo, ni he trabajado nunca, en IBM. Considero que no estoy haciendo publicidad alguna, pues todo lo que cuento lo he experimentado yo mismo y visto con mis propios ojitos, pero cuando hablo con muchos compañeros de profesión que nunca han trabajado con estos Sistemas, me doy cuenta del enorme nivel de desconocimiento que existe en la actualidad acerca de esta gama de máquinas y sus aplicaciones.
En el próximo episodio, ahora sí, me centraré en el Lenguaje Cobol, tal como prometí, y hablaré del Efecto del Año Dos Mil, qué fue y por qué ocurrió. Si es que todavía estáis ahí para escucharme…
Disfrutad de la vida, mientras podáis.
The Historia de un Viejo Informático. Los mainframes de IBM. by , unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial-No Derivative Works 2.5 Spain License.
{ 73 } Comentarios
Muy interesante esta entrega, al igual que las anteriores.
Sin embargo en ésta en concreto echo en falta algo más de detalle sobre los mainframes antiguos. Por apasionantes, y desconocidos, que sean los Z/Series actuales (que lo son), no resulta difícil encontrar información sobre ellos… Mientras que los comentarios y anécdotas de un técnico de sistemas que presenció las primeras etapas de la informática empresarial en España son un bien mucho más escaso.
En cualquier caso, muchísmas gracias por este episodio, los anteriores, y los que estén por venir.
Un saludo.
Impresionante. Me gustaría conocer como se lleva a cabo el cambio en caliente del hardware en estos sistemas. Los pasos a seguir y los mecanismos que, bien fisicamente o bien a través del sistema operativo, se implementan para poder cambiar por ejemplo, un disco duro o un banco de memoria sin que el sistema se vea afectado. Quizá para un siguiente artículo…
Seguiremos aquí pare escucharte .. o mejor dicho leerte.
Me gustaría saber por qué un sistema UNIX necesita tantos técnicos más para ser administrado, siempre me parecieron muy eficientes.
@ badaman , hombre, teoricamente en cualquier PC moderno se puede cambiar el disco en caliente. Yo mismo lo he hecho en uno de los mios. (por probar más que nada). El mérito es todo del software. Si la cosa está bien configurada es tan sencillo como quitar uno y poner el otro. El sistema operativo hace lo demás.
Brigo, por lo que yo he entendido no dice que un sistema UNIX necesite tantos administradores. Lo que yo entiendo es que si se sustituye una plataforma basada en mainframes por otro basada en UNIX, para que tenga unas capacidades parecidas se necesitarían tantos y tantos servidores que harían falta todos esos administradores.
Estoy bastante de acuerdo con el autor. Soy administrador de UNIX, y sé que un solo administrador puede hacerse cargo de una plataforma bastante grande, pero he trabajado en una empresa donde había un Z de estos, y tengo que admitir que nosotros no podíamos dar toda esa capacidad de proceso SIN PARAR en ningún momento. Mira que teníamos muchas aplicaciones en cluster pero aún así había periodos de no disponibilidad, pero en cambio en el Z no había esos periodos, creo que incluso actualizaron el SO en caliente sin parada.
Espectacular, como siempre. Yo he tenido la portunidad de ver a uno de estos bichos de cerca (por desgracia sólo verlo) y la verdad es que impresionan. ¡¡Y sueltan un calor de tres pares!!
En serio me está enganchando un montón esta serie…
Gracias a todos por comentar.
@Colossus: Es que no hay mucho adicional que contar, de verdad. Te coges las características de los mainframes de ahora, las divide s por 1000, luego le haces la raíz cuadrada, y tienes más o menos un IBM 370. Con discos tipo lavadora, cintas magnéticas de carrete abierto, etc… la tecnología de la época, similar a la del Century 200 que expliqué hace un par de entradas.
Si te digo que el mayor avance de la serie 370 fue la invención de la memoria virtual (la que conocemos todos ahora, todos los SO la tienen) quizá te hagas una idea. Antes que eso, si un programa no cabía en memoria había que hacer overlays a pedal (ahora descargo este trozo de código, y cargo este otro…). El ingeniero inventor de la memoria virtual fue Amdahl, que luego montó su propia empresa de ordenadores.
Y en esta falta aparente de novedades reside la potencia de los bichos estos. Todo funciona. Siempre. Los del mainframe odian los cambios. En fin, otro mundo del que estamos acostumbrados, que cada vez que alguien cambia una versión de algo, se organiza parda.
@badaman: Brigo (gracias) te ha contestado ya. La gracia es que esto se puede hacer hace muuucho tiempo. Cuando el software detecta un fallo en un componente (digamos una CPU), simplemente la aísla, y trabaja como si no estuviera. Cuando ha sido sustituido, la detecta y la reusa de nuevo. Los discos están siempre en algún tipo de RAID (si son muy importantes, espejados), aquí no hay problema. Hay acceso a todos los dispositivos externos por muchos caminos (unos más largos que otros, pero se puede llegar). Etc. No sigo: la diferencia está en el Software.
@Brigo: Creo que Baco te ha contestado lo mismo que yo te contestaría. Todas esas aplicaciones dando servicios combinados (no lo olvides) y con tanta carga, necesitarían una plétora de servidores UNIX. Administrar centenares de servidores UNIX, pasándose información de unos a otros por la red… es una locura de administrar. Alguna Gran Compañía de Telefonía Móvil tiene todos sus Sistemas en UNIX (bueno, en *IX, que es casi lo mismo), y cuando tenían un millón de líneas, pues vale. Con decenas de millones, y centenares de millones de llamadas diarias… tienen un plantel de técnicos de UNIX como la NASA. Bueno, exagero, pero muchos.
Saludos
Debo decirte que me ha encantado tu publicación. Especialmente porque llevo ya alrededor de 7 años trabajando con la IBM en el area de servidores (Z Series). Esto es algo que mucho de las actuales generaciones no conocen y no saben que esta tecnología fue la mejor en alta disponibilidad y que fue la base para todos los servidores de alta disponibilidad que conocemos y tenemos hoy en día.
Es impresionante como ha evolucionado tanto en practicamente unos cuantos años. Antes se hablaba de 32MB de almacenamiento y hoy hablamos de Petabytes, procesadores con sistema de enfriamiento interno a base de agua, microparticionacionamientos, virtualización y mucho es. No existe el limite ahora en tecnología. ¡Amo esta tecnología! Saludos, Simón
Me encantan este tipo de reportages detallados sobre la epoca “oscura” (the dark ages xD) de la computación. Y lo digo de esta manera ya que yo personalmente nací a mediados de la década de los 80 y este tipo de cosas me parecen de los libros de historia.
Yo si trabajé en IBM, y no ha contado nada apenas, sobre todo de la parte de comunicaciones.
Buen articulo. Saludos
Muy bueno. Yo he podido trabajar con mainframes IBM y Bull (hasta hace poco, ahora aunque sigo en esto he pasado de la informatica de gestion a otras cosas, y del COBOL a C++), y aunque al principio cuesta, es una gozada currar con los IBM, cuando te acostumbras a editar en ISPF es una maravilla; y el Intertest (creo que esto ya es una aplicación de terceros) va de lujo para depurar los procesos del online.
Los Bull (supongo que pocos aquí habrán currado con ellos) son mas feos; no hay menus, va todo por comandos, y el editor es peor; el “spool” es más rudiemtario, no puedes tener varias ventanas abiertas(esto supongo que es algo moderno tambien y no estaría al principio) pero al final tambien te acostumbrabas, eso sí, nada corre como un IBM con DB2!!
Ahora vivo entre C++, visual studio, no toco bases de datos para nada y estoy muy agusto, pero recuerdo todo aquello con cariño.
Y se me olvidaba! Gracias al autor, y a seguir con estos artículos, que son de lo mejor
Salud!
cada dia mas interesante, deberias escribir un libro de tuis memorias noveladas!!! yo lo compraria
Magnífico post. Yo estuve trabajando un corto espacio de tiempo en un sistiema MVS en una gran compañía de telecomunicaciones, y he de decir que ratifico todo lo que has dicho. Eso sí, había un botón rojo que…
Magnífica entrada. Espero que continúe pronto.
Queremos la segunda parte ya!!!!!!!!!!!!!!!
Aquí tienes un enganchado más
@Simon: Pues sí. Tienes razón. Por cierto, el primer ordenador refrigerado por agua fue precisamente el 3081 (años 80). Disipaba tanto calor que no hubo más remedio que hacerlo así. Como creo que es interesante, lo contaré más en detalle en próximas entradas.
@Jimmy Jazz: Efectivamente. El mundo está lleno de reconvertidos de Java, C y tal a Cobol. Todos lo odian al principio. Y lo añoran cuando vuelven al mundo “real” del “Java Runtime Out of Memory”…
Pero son cosas distintas, con sus ventajas e inconvenientes cada una, y que valen para lo que valen.
Ya digo: conocí una empresa que servía con su mainframe cerca de 3.000 transacciones pesadas por segundo. Y ojo: una transacción de IMS o CICS no es una transacción típica de UNIX: cada transacción puede acceder a ocho o diez tablas DB2 distintas, actualizar cuatro de ellas, leyendo algunos miles de filas, que hay que clasificar… Vamos, lo que se mayormente se llama una “transacción pesada”.
El objetivo del artículo es dar a conocer, hasta cierto punto, estos sistemas, sin entrar demasiado en detalle; por ejemplo, casi no he contado nada de las comunicaciones (el SNA y su ejecutor, el VTAM), que revolucionó el mundo y permitió el nacimiento del Online como lo conocemos…
Pero es que yo soy (fuí) un desarrollador. Malo, pero desarrollador, no soy Técnico de Sistemas. Lo que pasa es que en los 70 y 80, para sacar partido al aparato, había que conocerlo a tal nivel que, en realidad, sabías más sobre ella que un técnico típico de sistemas actual… Y también eran más sencillas entonces, eh?
Gracias a todos por comentar. El artículo se enriquece con vuestras aportaciones.
Macluskey,
Muy buenos todos tus artículos. No dejes de publicar, por favor.
Sólo decirte que IBM tiene un Web con un museo virtual de sus viejas glorias, ya sea equipamiento, tecnologías, instalaciones, gente, etc. Se puede acceder aqui: http://www-03.ibm.com/ibm/history/index.html Hay cientos de enlaces, fotografías y documentos, todos muy interesantes.
De acuerdo con #1
Me ha encantado, pero no has hablado nada de los antiguos.
Espero nos resarzas en la próxima entrega
saludos
La verdad es que a pesar de haber trabajado 5 años en IT y otros tanto como desarrollador, desconocía el verdadero potencial de los mainframes
gracias por compartir tu experiencia y felicitaciones por el blog, a más te leo más me gusta 
Yo soy administrador de sistemas variopintos pero solo tengo referencias de los mainframes, he tenido manuales en mis manos y los comandos son satanicamente indescriptibles y te lo dice alguien con amplia experiencia en Novell / Unixes / Windows.
Solo felicitarte por:
a) Lo interesante que es lo que cuentas b) Lo bien que cuentas estas cosas tan interesantes.
Espero el siguiente capitulo
Buenas
Muy interesantes tus post. Yo si vi caerse una VTAM, pero no me preguntes mucho porque era poco menos que un becario. Estabamos haciendo pruebas de rendimiento de una aplicacion para pasarla de ficheros bdam a db2 preformateando tablas y el caso es que el invento rendia mejor de lo que esperabamos, asi que supongo que la vtam se empacho y termino cayendo. Recuerdo que mi jefe (que si sabia el tio, no como yo, que creia que sabia) estaba muy tranquilo y de pronto se fue a hablar con uno de los tecnicos y que despues de eso empezaron a salir tipos de los despachos a preguntar que pasaba. Nos dejaron una de las cuatro maquinas para probar y la rompemos…
Ya no tengo nada que ver con MVS (lo deje porque pense que era “viejo” y buscaba cosas mas modernas) pero ahora desde la distancia recuerdo esos tiempos con cariño, porque eso si que era aprender.
Estas cosas las leí cuando estuve preparándome una charla histórico a los de primero de carrera. La verdad es que me quedé flipando es como iban solucionando los problemas que iban surgiendo con cada “actualización” para no perder la compatibilidad (el cambio de 16 a 32 bits, luego a 64, las cambios que eso supuso en la cantidad de memoria que se podía direccionar, y esas cosas) La verdad es que no me acuerdo donde lo leí.
Me encanta, llevo varias entradas leyendote y me impresiona mucho el nivel de esa epoca, debo decir que yo soy de los novatos, xdd
Por otro lado, has mencionado que incluso estropeandose el disco que contiene el SO puede seguir trabajando la máquina, podrias explicar un poco el porque
Saludos y sigue en tu línea
Me gustaria ver sites como facebook, youtube o incluso tecnologias como la de google corriendo sobre un mainframe y programado en cobol… digo, a quien quieres engañar de que es algo maravilloso?, lo fue, sin duda, pero hoy dia no es mas que un gran mamut. Y eso de que necesitas “cientos” de administradores para un sistema UNIX es tal vez porque nunca has conocido a los buenos administradores, incluso con muy pocos se pueden administrar redes realmente muy grandes (y cuando digo grandes me refiero a redes que superan varias veces a las de un misero banco). Me encanta la nostagia pero hay que evolucionar, no involucionar. Incluso ninguno de los clusters mas grandes de la tierra (top500) usa z/OS, por el contrario, usan Linux y por si fuera poco la mismisa “Roadrunner” (que es de IBM) usa Linux…
@haplito: ya contesté antes a colossus: Si te miras las dos entradas anteriores, verás cuál era la tecnología de la época. O sea, la n-milésima parte de la potencia actual. Pero básicamente el Sistema Operativo y los productos base ya estaban ahí, dando servicio (aunque no el DB2, precisamente, cuya primera versión utilizable fue hacia 1988 o así).
@cruzki: Desde los 370, el direccionamiento era de 24 bits (hasta 16Mb por región), o sea, tres bytes. Pero los registros generales son de 32 bits (4 bytes), por lo que pasar a direccionar con 31 bits (no con 32 porque el primer bit de los registros se usa para marcar ciertos códigos de condición) y direccionar 2Gb fue relativamente sencillo: ya la versión MVS/ESA, sobre 1985 o así, permitía direccionar más de 16Mb (aunque, sinceramente, entonces a nadie se nos ocurría PARA QUÉ demonios habría nunca que direccionar más de 16Mb… ¡Ilusos!!).
El cambio de 31 bits a 64 (quizá 63, no estoy seguro) tuvo muchos más bemoles, pues era vital garantizar la compatibilidad. La solución es, desde luego, que lo hace todo el S.O., y tú no tienes (casi) que preocuparte por ello. Y yo creo que es poco menos que imposible que un programa de usuario necesite direccionar más de 2 Gb ¿Tú sabes cuántas instrucciones caben en 2Gb, a una media de unos 4 bytes por instrucción?? Unos quinientos millones. ¿Os imagináis un programa de algunos cientos de millones de instrucciones…? Uff
Gracias por los comentarios
Muchas gracias por este pedazo de articulo. Ahora soy Administrador de servidor de aplicaciones Web ( Weblogic i-planet) He llegado aqui desde el mundo de los MainFrame, la verdad que solo siendo operador y lo que eso conlleva en temas de horarios ( 7 x 24) al ser la maquina tan buena se trabaja siempre jajajja. El caso es que yo estaba encantado con ese sistema y trabajar para ello ( lo deje porque tenia un jefe un tanto asi y por los turnos que era un poko jodido, luego no habia posibilidad de cambiar de departamento) y me ha hecho recordar bueno tiempos en los que aspiraba a manejar esto como a lo mejor lo haces tu, pero bueno por otras circustancias cambio. Sigo teniendo contacto con mis compañeros del banco para el que yo trabajaba y cuando veo noticias que implican a los Mainframes o algo sobre sistemas de banca siempre leo porque me parece muy interesante todo esto. Ademas en el instituto tuve la posibilidad de tocar y leer algo sobre cobol, pero la verdad que muy poquito y apenas me ha servido para nada… me gustaria saber mas sobre todo esto jeeje. Prestare atencion a tu entrega de Cobol a ver que podemos sacar aprender e incluso retomar. Un saludo y muchisimas gracias por este pedazo de articulo!!
Mac, 2 Gb llenos de código en cobol, como que es un poco difícil, pero los amigos de VI$TA sí que saben como ocuparlos de tal forma que apenas puedas notar la diferencia con un equipo 10 años más antiguo (igual que IBM pero al revés
.
Me uno al grupo de los que les ha sabido a poco el artículo. (Queremos más
Para el que no sabe, con ver la capa más externa: léase LOS RESULTADOS – consecuencia del HARDWARE, ya es suficiente. Pero a algunos más curiosos nos gustaría conocer más adentro: no el QUÉ hace sino el CÓMO: el SOFTWARE y en concreto el SO.
Me hubiera gustado conocer más acera de ese magnífico MVS y sus diferencias con los unix. Me intriga saber qué es lo que hizo que los conceptos aplicados a ese sistema operativo, no se extendieran a otros para tener sistemas con características similares.
¿Es que acaso se mantenía todo demasiado cerrado como hace apple? ¿O sería por el coste? ¿Eran conceptos que sólo se podían aplicar sobre un hardware demasiado costoso para ser descartados en equipos más asequibles y por eso no han llegado a la informática de hoy en día, 40 años más tarde?
@todos: Muchas gracias por los comentarios. No sé donde eterme… así que escribiré algún artículo más. ¡Lo siento por vosotros!
@Andy: Gracias, ya lo sabía… de hecho, esas fotos tan preciosas que están en los artículos de máquinas de IBM de hace mil años, son casi todas de ahí, aprovechando que nos dejan utilizarlas en aplicaciones no comerciales… lo que, evidentemente, es Elcedazo.
@joel: Mira, no te sé decir en dónde está la diferencia.
Sí que sé que el proyecto de desarrollo del MVS (OS/360 se llamaba por entonces, pero es lo mismo) fue en su día el proyecto más ambicioso y complicado que se había hecho hasta entonces, unos 3.000 ó 4.000 años hombre de trabajo.
Si estás interesado, su director de proyecto, Fred Brooks, una vez que salió del cotolengo donde tuvieron que recluirle para que recuperara la cordura, publico un libro de culto entre los informáticos (aunque supongo que desconocido para la gran mayoría):
“El hombre-mes mítico” (The Mythical Man-Month”; una búsqueda en la red os dará mucha más información). Aunque se centra sobre todo en las dificultades que surgieron al gestionar un proyecto tan gigantesco (¿os suena eso de “Añadir recursos a un proyecto retrasado, sólo conseguirá retrasarlo más”? pues es de Brooks), también cuenta cosas acerca del propio diseño en sí.
Y la clave es que desde el principio, el equipo de ingenieros tenía en mente las claves que debía tener el Sistema Operativo: Fiabilidad, Fiabilidad y Fiabilidad. No podían permitir que un cascotazo de un programa se cargara el Sistema completo, de ninguna manera. Diseñaron un sistema de gestión de tareas absolutamente modélico. Todo él está programado en Assembler, y ajustado hasta la última instrucción. Inventaron la memoria virtual (por allí andaba Amdahl, el auténico padre del invento).
En fin, prepararon unas especificaciones de diseño muy ambiciosas, y no se apartaron un milímetro de su objetivo… aunque el coste final fue tres o cuatro veces mayor del presupuestado. En fin, los proyectos entonces los dirigían ingenieros, y no financieros, como ahora, y ahí puede estar parte de la clave.
Y el SO ha evolucionado mucho desde entonces. Ahora no sólo corre aplicaciones Cobol antiguas: puedes poner un servidor Web, un servidor de datos, máquinas Java, y toda la parafernalia. Aunque, si sólo tienes que tener un servidor Web y uno de datos, mejor te compras un servidor Linux, eso es cierto.
Saludos
@Ezequiel: Muchas gracias por tu interesante comentario!
No tiene sentido empezar una discusión sobre si los mainframes son mejores o peores que otros sistemas, ni yo creo que yo haya dicho tal cosa en el artículo. Sobre todo, por que yo no deseo “CONVENCER” a nadie, sólo pretendo “INFORMAR”, y que cada cuál extraiga sus consecuencias.
Los mainframes son realmente buenos haciendo lo que hacen bien, valga la perogrullada, es decir, sobre todo: a) Correr aplicaciones que, a pesar de sus muchos años, siguen dando soporte al core business de las empresas, y b) Tratar muy bien cargas mixtas: Online pesado, Time sharing y Batch, simultáneamente en la misma máquina, y sin que se molesten en demasía.
Si eres Facebook, o Youtube, o incluso la propia Google, como comentas, no te vas a comprar un mainframe… ¡porque tu propio legacy está en otros tipos de máquinas!
Todas empezaron “en un garaje”, con una tecnología de andar por casa, pero muy bien parida, y tuvieron éxito… a pesar de los reconocidos fallos clamorosos de seguridad de Facebook, o los errores de Google que últimamente están apareciendo, que seguro que no son debidos al hardware o al software básico, sino a algún programa fallón o algún humano distraído. Así que, no sé si de grado o por fuerza, tienen los sistemas que tienen, y no van a cambiar, ni se lo plantean, como no va a cambiar ningún banco, ni ningún ministerio, por las misma razones.
Cierto que los sistemas más “aparatosos” de IBM (Roadrunner, Blue Gene, etc) funcionan con tecnología Linux… o AIX. Porque son máquinas de la serie RS/6000, las máquinas AIX de toda la vida (bueno, desde 1990) y por motivos de marketing (y, qué demonios, de tocarle las naricillas a Microsoft) también Linux en los últimos años. Son más baratas, claro, pero… ¿te has dado cuenta que la mayoría son monoaplicación? Jugar al ajedrez, buscar estructuras de proteínas, la determinación del genoma, cálculos metereólogicos, etc. Yo no me compraría un mainframe para estas aplicaciones, que básicamente (pero no sólo) requieren fuerza bruta. Es mucho más barato así, qué duda cabe.
Deduzco por tu comentario que eres (o conoces de cerca a) un muy buen administrador de sistemas UNIX. ¡Mi enhorabuena, Ezequiel!! Porque hay poquísimos, y están todos muy bien pagados. De hecho, por mucha crisis que haya, seguro que muchas empresas están deseando contratarte (o contratarle), incluída la mía (que no es mía, claro, es donde trabajo).
Y efectivamente, tanto Sun (sobre todo desde que compró a StorageTek) como Hewlett Packard (desde que compró a Tandem) ofrecen tecnologías fault tolerant y estabilidad en los sistemas muy poco habituales en otros sistemas UNIX… sólo que desde hace cinco o quizá diez años. Los mainframes, desde hace treinta.
Que tienen un mercado cautivo, desde luego que sí. Que ganan dinero con la división de mainframes, es público y notorio. Pero que sus clientes estén a disgusto, deseando cambiar a otros sistemas más modernos… te puedo garantizar que de ninguna manera, y conozco, por unas u otras razones a muchos CTO’s españoles que tienen mainframes.
No es una tecnología obsoleta. Para nada. Es cara, de entrada, y sólo determinados proyectos empresariales proporcionan el ROI suficiente a medio plazo para que una nueva empresa decida entrar en esta tecnología, es cierto.
Y, claro, la maquinaria de marketing de los competidores de IBM, todos a una, con aquello de ¡Son Dinosaurios!!, es muy poderosa, y ya estuvieron a punto de cargársela en los años 90, como quizá tengamos oportunidad de ver en próximas entregas.
En cualquier caso… ¡en la variedad está el gusto!
Y repito, muchísimas gracias por traernos tu punto de vista.
Saludos
Hombre, es que cada cosa es para lo que es. Un mainframe es un sistema centralizado que soporta una carga de entrada/salida brutal, miles de transacciones CICS, acceso a datos, etc… Los cacharros del TOP500 son unos bicharracos que lo que tienen es una capacidad de calculo de la leche. Por eso se usan para simulaciones y demás. Ni un mainframe está hecho para hacer cálculos científicos, ni un cluster del TOP500 está diseñado para acceder a bases de datos/ficheros.
Salud!
Esta claro que estas dos tecnologias por las que ahora discutimos tienen su uso y su objetivo. En el caso de los Mainframes lo que aportan es una seguridad y estabilidad que nadie puede darte… y para que se estan usando?? para transacciones gigastescas que necesiten seguridad… usease el dinero!! El riesgo que correria un banco o una aseguradora en migrar todas sus cosas a sistemas distribuidos es grandisimo, y la cantidad de datos que se podrian perder tambien. Estamos hablando a mi parecer de cosas diferentes de diferentes epoca que por su puesto pueden convivir conjuntamente. Muchas de estas entidades financieras tambien tienen sus sistemas UNIX. Y antes lo que se programaba para el banco y desde el banco solo puede ser usado alli y no hay mas que hacer. Con los sistemas de UNIX una cosa que programes es un sitio te puede valer para otro y viceversa. Y esto pasa por el momento en que se vive actualmente, antes no se barajaba la posibildad de hacer y sacar programas para que otros los usaran, solo querias hacer algo que le valiera a tu empresa. Ahora yo salgo de mi empresa y mis programas van conmigo, nunca se sabe donde puedo terminar y para que me pueden valer. Un saludo
¡Qué bien me habría venido este resumen cuando empecé a hacer mi proyecto de fin de carrera sobre procesamiento batch hace unos meses! Habría facilitado mi vida entre los Red Books de IBM.
Menos mal que estos cacharros son caros de cojones y el z/OS conocido por pocos, porque sino la mitad de los administradores estarían sin curro o aburridos viendo pasar las moscas. Creo que los mainframes volverán a tomar importancia gracias a la virtualización. Aunque la verdad, no sabría contrastar si varios Blades serían mejores ante un mainframe en este aspecto.
Otro genial artículo, como de costumbre Mac. Te has convertido ya en el líder de El Cedazo, en vistas, ¡enhorabuena!
Yo me vuelvo a mi cueva a filosofar, que veo no es algo tan masivo como la informática. ¿Filosofía e informática?, ¡¿qué comparación es esa?!, no, yo no creo en las comparaciones, sino en la aceptación de la existencia de una balanza ya destrozada por la elevada inclinación de uno de sus pesos… En fin, olvida lo que acabo de decir.
¡Enhorabuena amigo!. Saludos
@Lucas:
De ninguna manera, amigo. Que sepas que a mí me gustan mucho más tus artículos que los míos propios.
Lo mío no tiene mérito alguno: se trata de recordar en plan abuelete las batallitas de la juventud, no hay creación alguna.
Da trabajo, claro: hay que escribir la entrada, buscar documentación, fotos… pero no hay inspiración, sólo transpiración…
En tus artículos (como los de otros ilustres colegas de elcedazo) sí que hay creación… Y eso es lo que yo admiro de verdad.
Espero seguir leyéndote y aprendiendo.
Saludos!!
¡Muy bueno! Precisamente, hace un par de días un compañero Técnico de Sistemas UNIX me comentaba que no entendía el por qué del Mainframe. Y yo (Técnico de Sistemas z/OS) le intentaba explicar que cada sistema tiene su uso y que los A vs. B no tienen mucho sentido si no se les añade un contexto de para qué se van a utilizar. Por eso, es común que los buenos CPD sean un batiburrillo de tecnologías, sacando el máximo provecho de cada una.
En cuanto a los “la lista de los supercomputadores no incluye mainframes”… A ver, claro que no. Un mainframe (me refiero a un System z de IBM) es más que simplemente una arquitectura de CPU, incluye muchas otras cosas (software, arquitectura periférica…). Los supercomputadores se hacen juntando-muchos-núcleos-de-algo-potente y haciendo que se comuniquen bien, claro. Pero dan igual ciertas cosas que a un System z se le exige (grandes canales de comunicación muy fiables con el exterior, por ejemplo. Y cuando hablo de canales no me refiero a “pipes” sino a “channels”.). Hace unos años, los supercomputadores más potentes se hacían con procesadores “POWER” (de IBM): los mismos que llevaban los mainframes y los mismos (en cuanto a similitudes en arquitectura) que llevaban los Apple. Ahora los supercomputadores llevan procesadores “CELL”: los mismos que llevan las Playstation3 (y muy parecidos a los de la XBOX), los mismos que llevan los BladeCenter de IBM y los mismos que van a llevar los nuevos System z según anunció hace poco IBM. Pero ninguno ha llevado nunca un MVS-OS/390-z/OS como sistema operativo porque es un sistema que no podría gobernar la máquina (sin cambios, claro). Los últimos suelen decir que llevan Linux pero realmente es un sistema a-me-di-da. Es un Linux al que se le han cambiado muchas cosas para que saque el máximo provecho del supercomputador. Y lo mismo cuando antes se utilizaban otros sabores de UNIX. z/OS tiene muchas ventajas por ser monolítico… para ciertas cosas. Lo mismo pasa con las plataformas distribuidas: tienen muchas ventajas… para ciertas cosas.
Google o Facebook o pon-tu-gigante-web-preferido-aquí ofrecen un producto que no necesita la fiabilidad que ofrece un System z y su arquitectura CENTRALIZADA. Un ejemplo: - Si haces una búsqueda por la palabra “pepito” en Google desde Madrid y el Googlebot de la zona tiene indexada ya esta página, esta página te aparecerá como resultado. Pero si realizas la búsqueda en Arkansas, la página no aparecerá hasta dentro de unas horas cuando incluya la indexación de esta zona en su índice. El tenerlo así de descentralizado les ofrece la ventaja de la inmediatez para la zona “afectada” pero por contra, les crea el problema de los “cuadres” de índices y la desactualización de según qué zonas.
Siento las incorrecciones o errores que pueda haber en el comentario… Y vuelvo a repetir: muy buen artículo. ¡Enhorabuena!
Genial! Me ha gustado mucho…
Muy interesante el artículo. Siempre me han interesado los mainframe, sobre todo los de IBM. Poder llegar a administrar alguno de ellos debe ser una auténtica gozada.
@pakito: Muchas gracias por el aporte. Interesantísimo.
Me da la sensación de que casi todo el mundo se piensa que soy (o he sido alguna vez) técnico de sistemas de mainframes IBM.
Pues no. Siempre he sido del “lado oscuro”, o sea, de Desarrollo. Muy curioso, muy enterado… y muy viejo. Pero yo siempre he sido de los que conseguían romper algo a base de meter algún programa en un bucle…
pakito: Una proposición deshonesta:
¿A tí no te importaría escribir, desde el punto de vista de un conocedor de verdad de las tripas de la bestia, qué es AHORA y para qué sirve AHORA un mainframe?
Te comento que:
Hay un interés bestial en la red (sorprendente, pero cierto), que estoy viendo por la cantidad de gente que se interesa por esta pobres letras mías.
Hay un desconocimiento grande, pero mucha gente quiere saber más sobre el tema.
Yo no puedo dar mucho más de mí. Puedo leer algún redbook e intentar ponerme al día, pero eso no es nada comparado con la experiencia real de un administrador real de sistemas.
Y por fin, elcedazo te abre sus puertas. En realidad me estoy metiendo en el terreno del dueño de eltamiz, Pedro, del que elcedazo es una parte, pero creo, por lo que le conozco, que no tendría inconveniente alguno en que participaras como autor… igual que yo y otros más hacemos. Y usar el editor para escribir la entrada no es difícil (aunque es recomendable usar un editor de texto para escribirlo y luego copiarlo allí).
Piénsatelo!!
Un saludo
…Y gracias por comentar a todos.
Genial el artículo, como los anteriores y apuesto que como los siguientes
Yo siempre había considerado los mainframes como algo antiguo en el sentido de que si debían ser compatibles con programas viejos muy potentes no iban a ser. Claro que esto es fruto de la mentalidad de sobremesa actual en la que sólo se mira hacia adelante. Me alegro de que me hayas sacado de mi error, ¡gracias!
Hola gente, para el que le interese el tema, el amigo Kujaku tiene unos cuantos artículos muy buenos sobre mainframes en el blog “SIGT: Historias de bloggers con insomnio” http://sigt.net/etiquetas/mainframes . Desde como funcionan todos los módulos a como montarte un emulador para trastear en tu PC. Estaría bien que se pasara por aquí jeje
De hecho por lo menos una vez llevó un mainframe a una euskal party, y lo puso como servidor de algo (yo por aquel entonces no sabía nada de este mundillo, que pena…)
Un saludo a todos … S0C7 jejej
@Jimmy Jaz:
Muchas gracias por tu aportación. No conocía este blog, y es muy interesante: está escrito por un System Administrator de un mainframe de estos con mucha experiencia y se nota.
Haré referencia a esta página en siguientes entradas, ya que mi formación es como Desarrollador (programador, analista, Jefe de Proyecto, Jefe de no sé cuantas cosas, Consultor, Vendedor, bla, bla, bla… siempre ligado al mundo de los Proyectos mucho más que los sistemas.
¡Y también hablaré del S0C7 dentro de dos entradas, que ya está casi escrita…!
Saludos
Muy interesante este como otros artículos que he leido Yo he rozado algún pequeño sistema 36 y he llegado a instalar un Linux en una partición dentro de un z/OS con otro aplicativo…. Una decepción (a nivel Linux, por supuesto) en lo referente a rendimiento, pero creo que lo importante era demostrar que ambos aplicativos funcionaban en el servidor simultáneamente y se consiguió. Como bien dices esas máquinas tienen unas características de seguridad y compatibilidad con viejas aplicaciones (que no malas) que los hacen unos cachivaches que siguen teniendo su mercado.
Acabo de visitar el enlace de aquí arriba. He visto algunas capturas de pantallas, que se echan de menos en este artículo, para poder hacerse uno una idea de a qué se parece un sistema de esos, si alguna vez hemos visto algo parecido. (Seguro que en el próximo artículo saldrán).
Pues he recordado una de esas pantallas en un curro que tuve hace 7 años, allá por el 2002. Bueno, cualquiera puede haberlas visto en el banco cuando el que te atiende tiene que mirar una cosa “rara”, o cuando te vas a renovar el dni a la policía, en algunas ETT, etc…
El trabajo era de administrativo en un almacén de una cadena de supermercados, y usábamos terminales de un AS/400. Por más que busqué información, nunca llegué a entender qué era exactamente eso. Estaban conectadas a la central de Madrid por una conexión punto a punto, y se ve que todos los almacenes y supermercados del país también lo estaban.
Eran pantallas con menús, formularios y listas en las que hacías selecciones. Y los listados, los lanzabas como procesos y cuando estaban listos salía un mensaje de confirmación por pantalla.
La verdad es que aparte de hacer scripts de macros para usar en el cliente terminal, no se podía hacer nada más interesante. Es lo que tiene ser un simple usuario.
¿Es AS/400 un mainframe?
Un AS/400 es un mini (miniordenador, tiene su guasa pero es verdad jeje, ya que cuando le pusieron el nombre no había informatica personal, así que un ordenador era un mainframe, y los que eran sus hermanos pequeños eran minis; igual estoy diciendo barbaridades, pero creo que era así).
Ahora mismo se llaman iSeries (los mainframes son zSeries), y también soportan linux y todo eso. Tradicionalmente se usan en empresas medianas y son unos cacharros muy majos.
Salud!
@joel: Jimmy Jazz te ha contestado ya.
AS/400 es la evolución de los System/3x (32-34-36 y 38), y sa´lió al mercado allá por 1990. Todos estos sistemas se programaban mayoritariamente en RPG II, pero a partir de 1985 o así se pudo ya programar en Cobol u otros lenguajes. El S.O. del AS/400 se llamaba OS/400, y era el hermano pequeño de MVS, características parecidas, aunque menos “tocho” (y por tanto, más sencillo de configurar y mantener). Pero la idea es que fueran, para una empresa pequeña o mediana, la misma cosa que un mainframe para las grandes: El soporte de las operaciones críticas, con compatibilidad hacia adelante, etc.
Desde 2002 o así, a la gama AS/400 IBM la llamó iSeries, y admiten Linux, TCP/IP, y lo que sea… pero también los sucesores del OS/400, del CICS/400, del DB/2 400, etc.
En definitiva, con la potencia de los procesadores de ahora, es un mainframe pero menos potente, más barato y con su propia historia… que no conozco muy bien, por cierto.
Espero que esto te haya ayudado.
Saludos
@Ezequiel: creo que no se trata de abrir ninguna polémica de unas platoformaas contra otras. Yo creo que cada una tienen su razón de existir, su sitio en el mercado. Y los Mainframe siguen teniendo razonas para muchísimas grandes empresas de todo el mundo, después de más de 40 curenta años desde su nacimiento: no hay ninguna otra platforma que pueda decir/demostrar lo mismo. Como tampoco hay un sistema operativo ni un lenguaje de programación que sea el mejor en todas los aspectos y para todas las industrias…. Sitios como Google, Youtube,…. quizás se puedan permitir el lujo de estar parados unas horas (como pasó hace unos días) o de perder unos cuantos vídeos o emilios: las institiuciones Financieras (principales ussuarios de los Mainframe), NO. Los Mainframe no son ni mucho menos los diniosaurios que tú crees; quizás tu percepción es debida al gran desconocimiento que hay en el mercado de los mismos.. Ahora los Mainfram corren, además de z/OS y Cobol…., Linux. Son plataformas con múltiples tipos de procesadores: no solo tienen sus procesadores centrales (hasta 64 configurables), sino que también tiene cientos de otros procesadores repartidos por su subsitema de entrada/salida o sus asistentas criptográficos por HW o, más recientemnete….. ¿Quieres ver un sitio divertido que corre en Mainframe? Mira estos enlaces : http://www.hoplon.com/content/view/6 http://www.taikodom.com/
o éste video de youtube.
http://www.youtube.com/watch?v=p0e5NxKZaBA
Espero que ésto, que no es más que un ejemplo, sirva para cambiar la percepción sobre los Mainframe… los modernos Mainfarme.
Mac,
Déjame decirte que en tus artículos no sólo hay inspiración, sino que hasta son inspiradores. Mira toda la comuna de admiradores que te has ganado, ¡felicidades!
Aprecio de verdad el apoyo que me diste siempre. Saludos!
Me he leído los dos últimos artículos del tirón. Yo empecé en la informática precisamente en un banco adaptando programas en Cobol al año 2000 y a la llegada del euro. Incluso me tocó hacer ingeniería inversa de dos viejos programas en ensamblador (que daban mucho pero que mucho susto y empezaban a volverse inmantenibles) para implementar un programa en Cobol que hiciera lo mismo. ¡Ah, qué tiempos aquellos!
Deseando estoy de leer la próxima entrada.
Carámbanos y repámpanos, ¡51 comentarios! Has alcanzado el nivel de Pedro en sus mejores entradas. Mis felicitaciones Mackluskey. Boquiabierto me he quedado cuando me he dado cuenta.
Me quito el sombrero y hasta la peluca.
@ Mazinger,
Es totalmente cierto, pero no debemos olvidar que él es muchísimo más feo que yo.
@Pedro
Bueno, bueno… habría que ver cómo se conserva Macluskey. Igual duerme en un barril de formol y amanece cada día hecho un figurín…
Él mismo se ha llegado a describir como “viejo y desdentado”, pero el espíritu de sus artículos, pese a hablar de la prehistoria de la informática, no puede ser más joven, y clavar el diente en el meollo de la cuestión, aunque sea postizo, lo clava bien.
Aunque en pro de la justicia quisiera añadir que hay en El Cedazo artículos sobre otros temas (pongo a Lucas y su serie sobre el tiempo como ejemplo, pero lo mismo podría decir sobre Gustavo y los demás) que pese a no ser tan seguidos, o al menos tan comentados como los de Macluskey, no por eso tienen menor calidad.
Creo que la filosofía tiene menos seguidores que la informática. ¡Y ojo, que no le estoy restando mérito a Macluskey, que es un auténtico crack!
Perdón Macluskey, olvidé mencionar que me ha gustado mucho tu artículo. Yo he seguido, en cierta forma, tus mismos pasos…., a grandes rasgos. Soy de las últimas generaciones del Plan 77 de la Facultad de Informática….por tanto, un poco más joven que tú, ejem….De alguna manera, siento cierta envidea cuando oigo a gente como tú hablar de cómo se exprimían al máximo los pocos KBs/MBs de memoria, o la escasa potencia de proceso, a base de un conocimiento profundo de los lenguajes y las arquitecturas que manejábais… Ya no se estila ese tipo de ‘fina’ programación: ahora es más cuestión de echar más GBs o GHz y dejar el ‘arte’ de la progración para la historia de la informática….Se sustituye el músculo del cerebro humano por el del siliceo…..Snifff. Por favor, sigue con la saga…
Emmmmm. Por partes.
Pedro: Pero…¿Cómo te atreves a llamarme feo a MÍ? ¿A MÍ, que fui “Canastilla de Oro” al bebé más guapo en el concurso de 1955??
¡Qué deshonor para alguien tan ex-guapo como mi menda!!! Aunque ahora sea un viejo desdentado, quien tuvo, retuvo. Hooombre!!
Mazinger: No, porfa, no, no te quites la peluca. Para alguien con poco pelo, ya hay alguno por acá…
Y tienes toda la razón, lo dije ANTES Y LO REPITO: Los artículos de Lucas o de Gustavo, o de Belerofot, por comentar las series que están ahora más activas, tienen un nivel intelectual muy muy superior a las mías, sin duda alguna. Pero leñe, si Lucas hasta ha conseguido que un palurdo como yo haya entendido a Kant!! lo que pasa es que mis artículos osn puro folklore, y mucha gente se siente identificada con ellos por unas u otras razones, pero mérito, mérito… el que tiene buscar las fotos y los links, que no es moco de pavo.
Y lo del número de comentarios, primero que la mitad son míos (ya sabes, el autobombo…), y ni de coña llego al nivel de algunos artículos del Jefe, que deben llevar como 200… sin ir más lejos el de la falacia “El hombre jamás ha llegado a la Luna”, estoy seguro que todas las semanas tiene que eliminar algún comentario de algún magufo poniéndole a parir…
@tavito: Tú te dá cuénnn?? Somos Legión, lo que pasa es que somos calladitos, porque los de nuestra generación somos mayormente currantes y no nos vamos pavoneando por ahí, pero qué buenos éramos. No, ¡SOMOS!, qué leñe.
…Y tienes toda la razón: Hoy en día cuando algo no va bien, se le ponen siete procesadores más y 400 Gigas, y hala!! Es posible que sea más barato a la corta, pero, bah!!, qué aburrido!!
………. Me voy a tener que re-revisar los capitulos del resto de la saga, porque como en uno baje un poco el pistón… me vais a crucificar. ¡Qué mieedo!!
Ya he comentado en este post, pero quería dejar otro comentario para dejar claro que el zSeries no es ningún dinosaurio.
No solo se siguen manteniendo por compatibilidad con aplicaciones viejas. Conozco algunos casos en los que se ha optado por los Z para aplicaciones completamente nuevas que podrían haberse desarrollado para UNIX. Estoy hablando de compañías de seguros, Administración Pública, etc…
Teniendo en cuenta el precio de un chisme de estos te aseguro que si hubiesen podido optar por cualquier otro sistema con UNIX lo habrían hecho, porque les habría salido bastante más barato. Me estoy refiriendo a más de 6 millones de € de precio de venta solo el Z (a lo que hay que sumar la cabina de almacenamiento externo, librería de cintas, etc…).
Y me ha encantado la frase de redes más grandes que las de un “mísero banco”. No sé a que redes/sistemas se refiere, pero dudo que haya muchas redes mayores o más complejas que las de Bank of America o UBS.
Y que conste que yo soy de UNIX.
Hola:
Me he estado leyendo algunos comentarios, pero queria dejar claras algunas inexactitudes que se han vertido por aqui, simplemente a modo educativo:
Empecemos con el direccionamiento de 24, 31 y 64 bits:
Las máquinas S/370 soportaban 24 bits de direccionamiento. Eso hace que se puedan direccionar hasta 16 MB de memoria por un simple programa. Pero llegaba un momento en el que los programas no podrían caber en memoria y se ideo la arquitectura de 31 bits con la arquitectura S/370/XA. En realidad, eran 32 bits, pero el bit mas significativo se utilizaba para DIFERENCIAR los espacios de memoria o address-spaces. Esto suena un poco lioso, pero basicamente era para saber si un programa COBOL escrito con la generacion de 24 bits se diferenciara con un programa escrito en 31 bits, ubicandose en el espacio de direcciones de 24 bits o 31 bits, dependiendo del bit. Asi que con 31 bits, lo máximo que se podia instalar en mainframe eran 2 GB. 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 que no te apetecia recompilar, y por encima de la línea, los programas nuevecitos paridos por tu compilador preferido. Con la llegada de 64 bits, con posibilidad de direccionar hasta 16 EXAbytes, creo que por unos años estamos preparados para no poder ubicar en memoria nuestros programas. Pero claro, de “G hasta 4 GB, como esta ese bit 31 que se usa para otra cosa que no es direccionar, tienes 2 GB de RAM no direccionables por arquitectura, y a esto, se le llamo LA BARRA.
Mas cosas: Si un disco de SO se rompia, en el peor de los casos, podrías perder algunos programas producto, pero por norma general, el MVS no te entra en un volumen solo (y aunque te entrara, era del genero bobo meter todo en un unico punto de fallo) por lo que los RESIDENTES (si, asi se llamaban el conjunto de discos del SO) estaban distribuidos en distintos discos, con distintas LCUs y distintos armarios. Ademas de esto, tenias utilidades tales que LLA, VLF, etc, que leian en tiempo de carga las librerias mas importantes de trabajo y las ubicaban en memoria, como si de una “cache” se tratara, asi que la rotura de un disco residente con la maquina en produccion y encendida, podria ser solventada con otro disco distinto, pero formateandolo con el mismo volser que el residente, grabando su texto IPL y recuperando de cinta la imagen de ese disco (y luego, poniendolo online) -el punto verdadero de fallo no es que se rompa el disco del SO, sino que se rompa el disco donde estuviera el Master Catalog, eso ya era el acabose (ya que las librerias SYS1 que pertenecen al SO solo se catalogan alli). Pero vamos, como tambien haces copias de catalogos a modo de backup con el IDCAMS, pues vamos, el fallo es minimo.
Afortunadamente, en 1990 del sistema de discos IBM 3390, armarios azules tan grandes como 3 armarios roperos puestos en fila, se fueron cambiando progresivamente por los IBM RAMAC, que eran cajones de discos en RAID-5 con un disco Spare, que a su vez “emulaba” un numero de discos 3390 (4 si era RAMAC1, 8 si era RAMAC3 y 12 si era RAMAC3), asi que si se producia una rotura fisica de un disco, el spare cubria su lugar, y si se volvia a romper otro disco fisico DENTRO de ese array (improbable, pero no imposible) todavia con la paridad se podria calcular el dato, asi que el fallo “logico” de un disco era literalmente imposible -a menos que IBM no viniera con celeridad y con dos discos en su macuto para arreglar el estropicio-. Despues de los RAMAC, vinieron los 2105 “Shark” y competidores como Comparex, Hitachi y EMC entraron en juego porque sus discos eran compatibles y mucho mas baratos… pero al final, lo barato sale caro, os lo digo yo. Despues del Shark, vino el ESS-800 y ahora tenemos los 8100 y 8300, que en lo que te ocupa un frigorifico “combi” tienes 400 TB de nada, con storage controllers redundadas, raids de todo tipo, y discos de 15.000 rpm fiber-channel.
Con respecto a que se pare el sistema una vez al año, recuerdo que en una instalación no lo paramos en 2 años y medio, y fue porque el JES2 (el subsistema de entrada de trabajos) tenia los volumenes de SPOOL llenitos y nos estaba marcando un SHORTAGE, no por el hecho de no borrar trabajos ya listados, sino porque el CICS escribia muchos logs y no querian pararlo jamas de los jamases, y claro, aunque solo te quede un proceso activo en el JES2, si te ocupa con listados de mas de 150 GB de texto plano de logs de transacciones, y llena el solito todo el SPOOL, pues os podeis imaginar.
De todas formas, ahora tampoco es cierto que cuando cambias de version el SO no se para, por norma general, antes de subir de version, es necesario instalar un buen numero de PTFs o fixes de compatibilidad, y algunos de ellos, al aplicarse, son SYSPLEX-Wide y eso obliga si tienes un parallel sysplex (es decir, varios mainframes conformado un super-mega-cluster paralelo), tener quesacarlas del sysplex, osease, parar las particiones o las maquinas para que se puedan aplicar, y como unas son requisitos de otras… vamos, que yo JAMAS he visto que se cuelgue un mainframe, pero si quieres estar al dia con el software, por lo menos una vez cada 3 o 4 meses te va a tocar parar la instalación 2 minutos, cosa que suele hacerse tipico domingo a las 4 de la madrugada, mientras todos andais de fiestuki.
Sigo con gran interes tus articulos, ya que yo soy de sistemas mainframe de toda la puta vida de Bilbao (dicen que los mainframes son los i-pods de los bilbainos, aibalahostia, je, je), y en desarrollo me he metido muy poco, asi que los ciclos de vida de analisis y el encomiable trabajo que haciais es muy muy interesante.
@kujaku: ¡Muchas gracias por tu intervención!!
No sé si has leído la última entrada, donde enlazo a varios de tus artículos, puesto que tu conocimiento real sobre z/OS es (obviamente) muy superior al de este pobre viejo programador metido a Jefe de Proyectos de Kojones…
No obstante, tienes que tener en cuenta que los artículos de esta serie intentan ser descriptivos, sobre todo para gente que no sabe ni que los mainframes existen (que los hay a millones), y con que se queden con la información suficiente, para profundizar, por ejemplo, en tus comentarios, que son excelentes…
Por ejemplo, la idea es que parar un z/OS se hace poco menos que por sport, porque caerse, en la vida. En Madrid es que somos así, y por Navidad se hacía un IPL en frío, apagando la luz y todo; claro que ahora con los Bancos en Casa, las Tiendas en Casa, y la Biblia en Casa, igual ya no se para ni siquiera en Navidad, no estoy seguro… ¡es que yo soy de los del Lado Oscuro de Desarrollo!.
Sólo una precisión a tu (excelente, as always) comentario: Yo recuerdo en los tiempos del cólera del MVS a secas, que el primer bit de los registros generales de direccionamiento o lo que fuese lo machacaba siempre con algo (quizá el bit de condición… por más memoria que hago no me acuerdo qué metía allí). Pero si usabas una instrucción LA para algo que no fuera direccionar, te encontrabas a veces con sorpresas si no habías limpiado el registro antes. Cuando vino el XA (ni San Pedro quiso ponerlo al principio, porque no había ni un sólo programa que necesitara más de una o dos megas, así que…IBM metioó más y más información en las tablas internas del IMS, del CICS… hasta que eran ellos eran los que no cabían, y hubo que cambiar), no importó nada, pues ahora usaba los siete bits entre el bit 2 y el 8, y ya está. Y seguramente seguía usando el primer bit para lo que rayos lo usara, no lo recuerdo, porque, si con XA no lo usaba ya… ¿por qué no usar los 32 bits?. No tiene sentido. Yo creo que fue con la arquitectura “z” cuando aparece lo de la raya, la línea y la berza… Pero insisto: hablo de memoria de hace veinte años, así que… puede que no dé ni una.
… y ¡Cómo me gustaría jugar con un iPod como el tuyo, aibalaostia! En el mío no cabe ná!
Muchas gracias por tu comentario. Hasta otra!
@Macluskey: Pues si tienes oportunidad de venirte por Bilbao a la Euskal Encounter (www.euskal.org) que se celebra la última semana de Julio, tendrías la oportunidad de poder jugar tranquilamente y a tu aire con un z800 conectado a dos sistemas ESS-800, con varias LPARes (algunas con Linux que dan servicios a los asistentes), ya que yo cada año llevo alli una instalación completa (si, son cosas de tener un hobby voluminoso
)
Despues de 10 anos estoy nuevamente trabajando con mainframe, y encontrarme este tipo de articulos me traen gratisimos recuerdos, mi edad es de 58 anos, yo empeze a trabajar en un sistema 360. Felicidades Makluskey.
Gracias, McCluskey. No sólo recordé los “tiempos heroicos” cuando trabajábamos dentro de la “pecera” con aire acondicionado (¡Brrr!), sino que me agregaste conocimiento sobre estos nuevos monstruos. Es cierto que la info está, pero no tan bien resumida. Trabajé con /360, /370, 43xx, y también Burrougs (B-3000) y Bull (DPS-7) antes de dedicarme a la Web, pero nunca en proyectos tan complejos. Abrazo de un colega.
Muy bueno el post, pero tenemos un mainframe y lo paramos varias veces al mes. Haciendo ipl. Tambien hemos tenido que hacer algun POR. Como todo se cae pero si es verdad que al estar todo redundado y tener pocos puntos de fallos es mas dificil. Una vez recuerdo que se fue la alimentacion al fregar la zona adyacente y mojarse.
Llevo más de 35 años trabajando con ordenadores, empece con los 360/40, luego pase por un 370/125 m´sa un 370/145, he trabajado también con Es/3090 y actualmente con Z/os creo que con este último sistema se pueden virtualizar cientos de Lpars para trabajar con Unix y Windows entre otros, para mi una joya de máquinas, allí donde está el “negocio de las grandes empresas” los sistemas Windows se nutren de sus bases de datos (en este tipo de empresas) y en el fondo las técnicas que utilizan por ejemplo de gestión de usuarios son copiadas de los mainframes solo que para entornos distribuidos así como de sistemas Unix. El entorno gráfico es lo que le da vida a Windows.
Muy cierto Mcluskey. Yo trabajo en entornos windows con .NET. Nada que ver con la estabilidad y la robustez del AS/400, el único mainframe que he tocado.
Hola al compañero informatico, yo tambien soy de su época y me identifico con todo lo que ha relatado. Actualmente estoy por instalar un mainframe zEC12 de 10,000 MIPS y mas de 15 teras de storage. Las operaciones en batch y linea superan los 300 millones de operaciones mensuales. Así que es toda una monserga lo que hay que mantener ESTABLE. El cliente siempre exige lo mejor como si fuéramos sus esclavos, y gracias al mainframe cumplimos con todos los SLAs. En fin ahora tengo 58 y creo que seguiré en esto buen tiempo mas y la mayoria de mis compañeros son menores y nos hacen burla de la pantalla verde de ATARI dicen, jajajaja, y ellos no salen de su windows o cuando mucho unix o linux con oracle o Udb2. No saben nada de DB2, IDMS, IMS, ADABAS y la programación de user exits en assembler . En fin creo que nos iremos algunos a la tumba con conocimientos que jamas podremos transmitir a las nuevas generaciones. Yo he elaborado todos los cursos para formar system programmers de mainframes salidos de universidades privadas y publicas, pero solo he tenido la fortuna de capacitar a 25 jóvenes entre hombres y mujeres y eso fue hace 5 años. Espero que alguien más se interese por capacitarse en estos cursos y pueda aprovechar estos conocimientos para nutrir la demanda de profesionales de IT Specialist en mainframe que demanda el mundo, concretamente en México y America Latina.
Saludos
@Manuel:
Sí, sí… pantalla de Atari, pero siguen siendo las máquinas que hacen que el mundo gire. Incluso ahora, en pleno siglo diecinue… ¡veintiuno! Es una pena, pero parece que hay una confabulación mundial para eliminar los mainframes que nunca se caen y poner en su lugar maquinetas que se caen cuando menos te lo esperas, fastidiando todo lo habido y por haber. Pero, claro, son máquinas “modernas”, con “tecnología sofisticada”…
En fin. No comments.
Hombre, no creo yo que la informatica sea la mejor rama del mundo para criticar “tecnologia sofisticada”, como si un mainframe de hace 30 anos fuera un botijo con solera. Pero bueno, como una vez me dijo un amigo mio cabrero, rondando los noventa, el mundo no ha cambiado nada, los jovenes siguen pensando que los mayores no comprenden el mundo moderno y los mayores pensando que los jovenes no estan aportando ninguna mejora al mundo, lo mismo que cuando a alguien se le ocurrio hacer un cuchillo de dos filos, en que podia mejorar eso la buena piedra afilada por un lado de toda la vida? como iban a saber manejarla y ver sus obvias ventajas aquellos acostumbrados a usar solo un filo?
Informacion muy util para mi introduccion a un ambiente mainframe
Miren esta belleza: http://hipertextual.com/imagen-del-dia/ibm-1401
Estimado viejo informático, este comentario tal vez estén muy lejos de tu nota del 2009 pero realmente es muy clara tu explicación y la más clara que encontré para hacerles ver a unos amigos, sin abrumarlos, lo que es un mainframe y sus capacidades. Porque los que trabajan con PC’s, o notebooks , etc, etc creen que tienen algo extraordinario.
Yo trabajo con mainframes desde hace 40 años. (Comencé en un 370/158). Y como la tecnología avanza tan veloz a veces perdemos el hilo de las capacidades de estas máquinas y encontré tu nota tan clara. ! Reconozco las utilidades de esos pequeños equipos, yo también los uso pero cuando hay que abrir un banco, mover una planta automotriz o construir un central nuclear……..y tener los datos asegurados…….
Gracias.-
Hola muy interesante tu articulo, sigamos ilustrando a los nuevos programadores y soporte técnico de los mainframes y distribuidos. Soy de la CDMX y escribiíun libro sobre como inicie en TI. Antes se llamaba sistemas.
Mi pseudónimo es Marino Guzmán en homenaje a mi bisabuelo de origen español y mestizo, soy de Michoacán México. Ing. en Computación generación 85 de la Fac. de Ing. de la grandiosa UNAM. Actualmente laboro en IBM.
La obra esta en amazon y se llama: “Medrar con el Mainframe”, espero lo puedas leer.
Saludos
Si bién trabajé con computadoras durante toda mi vida quisiera volver a los años 70. Nada como el olor a consolas, impresoras, cintas y unidades de disco por la mañana.
Robert:
Yo también querría volver a los años 70, jeje… ¡Y volver a tener veintipocos años!!
Pero sí, fueron años extraordinarios, donde había que conocer en profundidad cómo eran las máquinas en que corrían tus programas… porque si no, no cabrían en la memoria, en esos 32 ó 64Kb tan bien aprovechados de las máquinas de entonces.
Qué recuerdos.
Gracias por comentar.
{ 3 } Trackbacks
Historia de un Viejo Informático. Los mainframes de IBM…
Continuación de esta serie de articulos dedicados al trabajo de informático en los años 70….
[...] » noticia original [...]
[...] Historia de un Viejo Informático. Los mainframes de IBM, de Macluskey (10 [...]
Escribe un comentario