Portada
mis comunidades
otras secciones
#6:
#3 No, para nada. Los zSeries siguen vivitos y coleando. Y muchas cosas que después se ven en otras arquitecturas aparecen primero para esos bichos. En ese sentido son como la "fórmula 1" de la informática.
El zOS (lo siento, no todos los system programmers lo seguimos llamando MVS ;)) tiene algunas cositas que tocan bastante los cajones. Para empezar:
- El lío de los AMODE/RMODE :). Los zSeries son herederos de los 360 y 370, que en principio eran máquinas con direccionamiento de 24 bits. Más adelante pasaron a 31 bits (sí, sí, 31, no 32), y luego a 64. El software escrito para las máquinas de 24 bits sigue corriendo en las máquinas de 64; sin embargo, un programa escrito para 24 bits no "entenderá" direcciones de 31 ni de 64, y según cómo esté escrito deberá "vivir" en un rango de direcciones de 24 bits. Cuando combinas módulos compilados hace 20 años con programas escritos antes de ayer esto te da más de un dolor de cabeza.
- La asignación estática de recursos. El sistema operativo intenta siempre garantizarte que tendrás todos los recursos que necesite tu programa durante su ejecución. Eso significa que los tienes que declarar: qué espacio en disco necesitarás, cuánta memoria vas a ocupar, qué tiempo de CPU máximo vas a emplear... Para ello se usa un engendro llamado "JCL". Buscad en google :). Uno acaba acostumbrándose a la "cosa", pero cuesta lo suyo. Sobre todo una instrucción concreta de JCL ("COND"). Viene a ser un IF, diseñado con la idea de volver loco al codificador. Una broma típica de los mainframeros es, al ver algo diseñado con el culo, pensar "esto lo hizo el mismo que parió el COND del JCL...".
- La gestión de la memoria compartida. El sistema operativo permite cargar en un área de memoria las piezas de código que van a ser más usadas por los diferentes procesos en máquina. Esto está muy bien... pero como todo el sistema está pensado en la estabilidad, si tienes que actualizar alguna pieza cargada lo que hace realmente el sistema es cargar otra copia. De este modo, los procesos que pueden estar usando la versión anterior ni se enteran del cambio. El problema es que el espacio compartido es limitado... y que si se llena tienes que hacer IPL (=rebotar) el sistema operativo.
Eso sí, ver un paral.lel sysplex de 10 monstruos tragándose casi 4000 transacciones online pesadas por segundo, con actualizaciones a bases de datos IMS y DB2, es digno de contemplar...
Ah, para acabar, desde las versiones 2.X del OS/390 (la encarnación anterior a Z/OS), existe un subsistema Unix (certificado por X-Open, por cierto), en el que aparte del "exotismo" de usar EBCDIC como página de códigos, cualquier linuxero se podría sentir bastante cómodo...
El zOS (lo siento, no todos los system programmers lo seguimos llamando MVS ;)) tiene algunas cositas que tocan bastante los cajones. Para empezar:
- El lío de los AMODE/RMODE :). Los zSeries son herederos de los 360 y 370, que en principio eran máquinas con direccionamiento de 24 bits. Más adelante pasaron a 31 bits (sí, sí, 31, no 32), y luego a 64. El software escrito para las máquinas de 24 bits sigue corriendo en las máquinas de 64; sin embargo, un programa escrito para 24 bits no "entenderá" direcciones de 31 ni de 64, y según cómo esté escrito deberá "vivir" en un rango de direcciones de 24 bits. Cuando combinas módulos compilados hace 20 años con programas escritos antes de ayer esto te da más de un dolor de cabeza.
- La asignación estática de recursos. El sistema operativo intenta siempre garantizarte que tendrás todos los recursos que necesite tu programa durante su ejecución. Eso significa que los tienes que declarar: qué espacio en disco necesitarás, cuánta memoria vas a ocupar, qué tiempo de CPU máximo vas a emplear... Para ello se usa un engendro llamado "JCL". Buscad en google :). Uno acaba acostumbrándose a la "cosa", pero cuesta lo suyo. Sobre todo una instrucción concreta de JCL ("COND"). Viene a ser un IF, diseñado con la idea de volver loco al codificador. Una broma típica de los mainframeros es, al ver algo diseñado con el culo, pensar "esto lo hizo el mismo que parió el COND del JCL...".
- La gestión de la memoria compartida. El sistema operativo permite cargar en un área de memoria las piezas de código que van a ser más usadas por los diferentes procesos en máquina. Esto está muy bien... pero como todo el sistema está pensado en la estabilidad, si tienes que actualizar alguna pieza cargada lo que hace realmente el sistema es cargar otra copia. De este modo, los procesos que pueden estar usando la versión anterior ni se enteran del cambio. El problema es que el espacio compartido es limitado... y que si se llena tienes que hacer IPL (=rebotar) el sistema operativo.
Eso sí, ver un paral.lel sysplex de 10 monstruos tragándose casi 4000 transacciones online pesadas por segundo, con actualizaciones a bases de datos IMS y DB2, es digno de contemplar...
Ah, para acabar, desde las versiones 2.X del OS/390 (la encarnación anterior a Z/OS), existe un subsistema Unix (certificado por X-Open, por cierto), en el que aparte del "exotismo" de usar EBCDIC como página de códigos, cualquier linuxero se podría sentir bastante cómodo...
#17:
#16 ¿Funciona? no lo toques.....
Y no estamos hablando de maquinas arcaicas con cinta y tios con bata blanca apuntando cuando se encienden o apagan luces, hablamos de 24 procesadores a 4.4 GHz y 1.5 teras de ram.
SISTEMAS DE ALTA ESTABILIDAD
Un banco no puede arriesgarse a un "Java Machine is out of memory"
Te lo digo yo que soy un reciclado de Java y .Net a Cobol (el curro es el curro).
Cobol es arcaico, no sigue la mayoria de los nuevos estandares de programacion, pero tiene sus virtudes (una vez que se acostumbra uno), y sobre todo, es estable
Yo veo por ahi en el TSO fuentes escritas en los 80, y esos programas aun estan en produccion, y sin protestar ni dar errores
Y como aputne friki, mi banco, tiene su propia herramienta para programar fuera del TSO, un bonito Eclipse tuneado con compiladores cobol y demás, para que veas que no es todo terminal de colores, eso si, el TSO sigue siendo fundamental
Y no estamos hablando de maquinas arcaicas con cinta y tios con bata blanca apuntando cuando se encienden o apagan luces, hablamos de 24 procesadores a 4.4 GHz y 1.5 teras de ram.
SISTEMAS DE ALTA ESTABILIDAD
Un banco no puede arriesgarse a un "Java Machine is out of memory"
Te lo digo yo que soy un reciclado de Java y .Net a Cobol (el curro es el curro).
Cobol es arcaico, no sigue la mayoria de los nuevos estandares de programacion, pero tiene sus virtudes (una vez que se acostumbra uno), y sobre todo, es estable
Yo veo por ahi en el TSO fuentes escritas en los 80, y esos programas aun estan en produccion, y sin protestar ni dar errores
Y como aputne friki, mi banco, tiene su propia herramienta para programar fuera del TSO, un bonito Eclipse tuneado con compiladores cobol y demás, para que veas que no es todo terminal de colores, eso si, el TSO sigue siendo fundamental
#35:
#32 te equivocas en muchos puntos pero solo te voy a contestar al último. ¿Assembler y COBOL? ¿de verdad crees que eso es lo único que soportan los mainframes? un mainframe soporta todo,lo viejo y lo nuevo. servidores de aplicaciones java, webfocus, c,etc. Además disponen del USS que es un entorno abierto dentro del mainframe, en el que puede correr shell script,... lo que quieras.
Los mainframes se han modernizado tanto o más que el resto de plataformas. Que corra lo viejo no quiere decir no corra lo nuevo. Si se sigue programando en COBOL es porque realmente es mejor para las necesidades de ciertos negocios, no porque las empresas estén atrapadas en él, ni mucho menos.
Los mainframes se han modernizado tanto o más que el resto de plataformas. Que corra lo viejo no quiere decir no corra lo nuevo. Si se sigue programando en COBOL es porque realmente es mejor para las necesidades de ciertos negocios, no porque las empresas estén atrapadas en él, ni mucho menos.
#1:
Los anteriores capítulos (muy recomendables), llenos de detalles que hoy resultan prácticamente cómicos:
Historia de un Viejo Informático. Introducción
Historia de un Viejo Informático. Los estudios: El Instituto de Informática
Historia de un Viejo Informático. El equipamiento informático en la década de los setenta
Historia de un Viejo Informático. El Método de trabajo en Proceso de Datos en la década de los setenta
Voy a leer éste y meneo.
Historia de un Viejo Informático. Introducción
Publicado hace 15 años por
--101913--
a
eltamiz.com
Historia de un Viejo Informático. Los estudios: El Instituto de Informática
Publicado hace 15 años por
macluskey
a
eltamiz.com
Historia de un Viejo Informático. El equipamiento informático en la década de los setenta
Publicado hace 15 años por
macluskey
a
eltamiz.com
Historia de un Viejo Informático. El Método de trabajo en Proceso de Datos en la década de los setenta
Publicado hace 15 años por
maxim.rudin
a
eltamiz.com
Voy a leer éste y meneo.
#22:
Hola
La persistencia del Mainframe no es por todas esas virtudes que apunta en el blog, que en realidad no son tantas (si yo tengo un sistema UNIX con la mitad de restricciones que tienen los mainframes ni me molesto en instalar los parches)
La persistencia del mainframe, la ha definido #17 si funciona, no lo toques
Pongámonos en la piel de un CTO de un gran banco, donde pasan miles de transacciones por un sistema obsoleto, pero que está adaptado a sus necesidades y que da un grado razonable de estabilidad (luego hablo del famoso 99.999%) y le dicen, si cambia sus sistema COBOL por un UNIX con Java (o C/++, ...) tendrá mas eficiencia y bla, bla, bla .... lo primero pregunta:
- ¿cuanto tiempo tardaría en sustituirlo?
- XX meses (siendo XX > 12 en el caso mas optimista que nunca se cumple)
- ¿y me garantiza que el banco no va a notar el cambio?
- Hombre, tras un periodo de adaptación .... no
En ese momento el CTO emieza a sudar la gota gorda y dice:
- Gracias, me quedo con mi COBOL
Yo he sustituido sistemas en producción y la cantidad de mierda que acaban acumulando es lo que hace inviable su cambio, no la bondad del sistema. Ejemplo real: un sistema de registro de averías de una gran empresa TELCO (creo que se entiende) hacía cosas como desconectar clientes (no tiene nada que ver con las averías) y el sistema que lo sustituye debe hacerlo o encargárselo a otro.
Con respecto al tan cacareado 7x24 de los mainframes .... será 24 días al mes 7 horas al día, porque el ordenador estará funcionando 7x24 pero los programas no. Requieren paradas cada poco (creo que no conozco ninguno en esa operadora que funcione 24 horas al día) por mantenimiento, backup, ... no permiten transacciones pesadas (2 segundos de CPU y te manda a tomar por el saco) ni SQL dinámico, ni tipos COMP-2, ...
Resumiendo: el éxito del mainframe fue llegar el primero, cuando nadie podía hacer lo que ellos y cautivar el mercado.
La persistencia del Mainframe no es por todas esas virtudes que apunta en el blog, que en realidad no son tantas (si yo tengo un sistema UNIX con la mitad de restricciones que tienen los mainframes ni me molesto en instalar los parches)
La persistencia del mainframe, la ha definido #17 si funciona, no lo toques
Pongámonos en la piel de un CTO de un gran banco, donde pasan miles de transacciones por un sistema obsoleto, pero que está adaptado a sus necesidades y que da un grado razonable de estabilidad (luego hablo del famoso 99.999%) y le dicen, si cambia sus sistema COBOL por un UNIX con Java (o C/++, ...) tendrá mas eficiencia y bla, bla, bla .... lo primero pregunta:
- ¿cuanto tiempo tardaría en sustituirlo?
- XX meses (siendo XX > 12 en el caso mas optimista que nunca se cumple)
- ¿y me garantiza que el banco no va a notar el cambio?
- Hombre, tras un periodo de adaptación .... no
En ese momento el CTO emieza a sudar la gota gorda y dice:
- Gracias, me quedo con mi COBOL
Yo he sustituido sistemas en producción y la cantidad de mierda que acaban acumulando es lo que hace inviable su cambio, no la bondad del sistema. Ejemplo real: un sistema de registro de averías de una gran empresa TELCO (creo que se entiende) hacía cosas como desconectar clientes (no tiene nada que ver con las averías) y el sistema que lo sustituye debe hacerlo o encargárselo a otro.
Con respecto al tan cacareado 7x24 de los mainframes .... será 24 días al mes 7 horas al día, porque el ordenador estará funcionando 7x24 pero los programas no. Requieren paradas cada poco (creo que no conozco ninguno en esa operadora que funcione 24 horas al día) por mantenimiento, backup, ... no permiten transacciones pesadas (2 segundos de CPU y te manda a tomar por el saco) ni SQL dinámico, ni tipos COMP-2, ...
Resumiendo: el éxito del mainframe fue llegar el primero, cuando nadie podía hacer lo que ellos y cautivar el mercado.
Comentarios
#3 No, para nada. Los zSeries siguen vivitos y coleando. Y muchas cosas que después se ven en otras arquitecturas aparecen primero para esos bichos. En ese sentido son como la "fórmula 1" de la informática.
El zOS (lo siento, no todos los system programmers lo seguimos llamando MVS ;)) tiene algunas cositas que tocan bastante los cajones. Para empezar:
- El lío de los AMODE/RMODE :). Los zSeries son herederos de los 360 y 370, que en principio eran máquinas con direccionamiento de 24 bits. Más adelante pasaron a 31 bits (sí, sí, 31, no 32), y luego a 64. El software escrito para las máquinas de 24 bits sigue corriendo en las máquinas de 64; sin embargo, un programa escrito para 24 bits no "entenderá" direcciones de 31 ni de 64, y según cómo esté escrito deberá "vivir" en un rango de direcciones de 24 bits. Cuando combinas módulos compilados hace 20 años con programas escritos antes de ayer esto te da más de un dolor de cabeza.
- La asignación estática de recursos. El sistema operativo intenta siempre garantizarte que tendrás todos los recursos que necesite tu programa durante su ejecución. Eso significa que los tienes que declarar: qué espacio en disco necesitarás, cuánta memoria vas a ocupar, qué tiempo de CPU máximo vas a emplear... Para ello se usa un engendro llamado "JCL". Buscad en google :). Uno acaba acostumbrándose a la "cosa", pero cuesta lo suyo. Sobre todo una instrucción concreta de JCL ("COND"). Viene a ser un IF, diseñado con la idea de volver loco al codificador. Una broma típica de los mainframeros es, al ver algo diseñado con el culo, pensar "esto lo hizo el mismo que parió el COND del JCL...".
- La gestión de la memoria compartida. El sistema operativo permite cargar en un área de memoria las piezas de código que van a ser más usadas por los diferentes procesos en máquina. Esto está muy bien... pero como todo el sistema está pensado en la estabilidad, si tienes que actualizar alguna pieza cargada lo que hace realmente el sistema es cargar otra copia. De este modo, los procesos que pueden estar usando la versión anterior ni se enteran del cambio. El problema es que el espacio compartido es limitado... y que si se llena tienes que hacer IPL (=rebotar) el sistema operativo.
Eso sí, ver un paral.lel sysplex de 10 monstruos tragándose casi 4000 transacciones online pesadas por segundo, con actualizaciones a bases de datos IMS y DB2, es digno de contemplar...
Ah, para acabar, desde las versiones 2.X del OS/390 (la encarnación anterior a Z/OS), existe un subsistema Unix (certificado por X-Open, por cierto), en el que aparte del "exotismo" de usar EBCDIC como página de códigos, cualquier linuxero se podría sentir bastante cómodo...
Los anteriores capítulos (muy recomendables), llenos de detalles que hoy resultan prácticamente cómicos:
Historia de un Viejo Informático. Introducción
Historia de un Viejo Informático. Introducción
eltamiz.comHistoria de un Viejo Informático. Los estudios: El Instituto de Informática
Historia de un Viejo Informático. Los estudios: El...
eltamiz.comHistoria de un Viejo Informático. El equipamiento informático en la década de los setenta
Historia de un Viejo Informático. El equipamiento ...
eltamiz.comHistoria de un Viejo Informático. El Método de trabajo en Proceso de Datos en la década de los setenta
Historia de un Viejo Informático. El Método de tra...
eltamiz.comVoy a leer éste y meneo.
#16 ¿Funciona? no lo toques.....
Y no estamos hablando de maquinas arcaicas con cinta y tios con bata blanca apuntando cuando se encienden o apagan luces, hablamos de 24 procesadores a 4.4 GHz y 1.5 teras de ram.
SISTEMAS DE ALTA ESTABILIDAD
Un banco no puede arriesgarse a un "Java Machine is out of memory"
Te lo digo yo que soy un reciclado de Java y .Net a Cobol (el curro es el curro).
Cobol es arcaico, no sigue la mayoria de los nuevos estandares de programacion, pero tiene sus virtudes (una vez que se acostumbra uno), y sobre todo, es estable
Yo veo por ahi en el TSO fuentes escritas en los 80, y esos programas aun estan en produccion, y sin protestar ni dar errores
Y como aputne friki, mi banco, tiene su propia herramienta para programar fuera del TSO, un bonito Eclipse tuneado con compiladores cobol y demás, para que veas que no es todo terminal de colores, eso si, el TSO sigue siendo fundamental
Yo curro con uno de estos y el entorno es MUY árido (bueno, y que el banco para el que curro no gasta un chavo en herramientas) pero hacen cosas realmente impresionantes. Lo que realmente me enfada es ver a los informáticos "de última generación" asociando informática con su windows o sus kdes y no tienen ni idea de la tecnología realmente profesional que está dando soporte a esas pequeñas cosas que hacemos a diario.
Hola
La persistencia del Mainframe no es por todas esas virtudes que apunta en el blog, que en realidad no son tantas (si yo tengo un sistema UNIX con la mitad de restricciones que tienen los mainframes ni me molesto en instalar los parches)
La persistencia del mainframe, la ha definido #17 si funciona, no lo toques
Pongámonos en la piel de un CTO de un gran banco, donde pasan miles de transacciones por un sistema obsoleto, pero que está adaptado a sus necesidades y que da un grado razonable de estabilidad (luego hablo del famoso 99.999%) y le dicen, si cambia sus sistema COBOL por un UNIX con Java (o C/++, ...) tendrá mas eficiencia y bla, bla, bla .... lo primero pregunta:
- ¿cuanto tiempo tardaría en sustituirlo?
- XX meses (siendo XX > 12 en el caso mas optimista que nunca se cumple)
- ¿y me garantiza que el banco no va a notar el cambio?
- Hombre, tras un periodo de adaptación .... no
En ese momento el CTO emieza a sudar la gota gorda y dice:
- Gracias, me quedo con mi COBOL
Yo he sustituido sistemas en producción y la cantidad de mierda que acaban acumulando es lo que hace inviable su cambio, no la bondad del sistema. Ejemplo real: un sistema de registro de averías de una gran empresa TELCO (creo que se entiende) hacía cosas como desconectar clientes (no tiene nada que ver con las averías) y el sistema que lo sustituye debe hacerlo o encargárselo a otro.
Con respecto al tan cacareado 7x24 de los mainframes .... será 24 días al mes 7 horas al día, porque el ordenador estará funcionando 7x24 pero los programas no. Requieren paradas cada poco (creo que no conozco ninguno en esa operadora que funcione 24 horas al día) por mantenimiento, backup, ... no permiten transacciones pesadas (2 segundos de CPU y te manda a tomar por el saco) ni SQL dinámico, ni tipos COMP-2, ...
Resumiendo: el éxito del mainframe fue llegar el primero, cuando nadie podía hacer lo que ellos y cautivar el mercado.
#32 te equivocas en muchos puntos pero solo te voy a contestar al último. ¿Assembler y COBOL? ¿de verdad crees que eso es lo único que soportan los mainframes? un mainframe soporta todo,lo viejo y lo nuevo. servidores de aplicaciones java, webfocus, c,etc. Además disponen del USS que es un entorno abierto dentro del mainframe, en el que puede correr shell script,... lo que quieras.
Los mainframes se han modernizado tanto o más que el resto de plataformas. Que corra lo viejo no quiere decir no corra lo nuevo. Si se sigue programando en COBOL es porque realmente es mejor para las necesidades de ciertos negocios, no porque las empresas estén atrapadas en él, ni mucho menos.
Todo esto, en mi opinión, pone de manifiesto un fallo de educación en informática bastante gordo: la absoluta ignorancia del mainframe y de su importancia. Hoy es perfectamente posible obtener el título sin haber oído la palabra "mainframe". Eso es como estudiar Ingeniería Naval y centrarse en los yates y las lanchitas, ignorando los transatlánticos.
#16 ¿En serio comparas JAVA y .NET con Cobol?
Java y .NET son coches de calle corriendo en un circuito y Cobol es un Formula1 doblandolos 20 vueltas.
Si con JAVA y .NET una aplicación normalita, consume un huevo de recursos imaginate tener que hacer todas las transacciones que hace un banco. El Mainframe no ocuparia una sala, seria el edificio entero.
Cuando leo este tipo de artículos me siento la mar de feliz de saber Java, .NET, Python, etc en vez de Cobol. Sin ánimo de ofender, es un lenguaje prehistórico que sólo sigue vivo porque a los bancos no les da la gana de actualizar sus sistemas.
Las trece colonias de Cobol emigraron por una buena razón a la búsqueda de nuevos planetas habitables...
#28 No dudo sobre la buena base formativa. Y aún añadiría que los conceptos que se dan, no sólo de arquitectura, sino de Sistemas Operativos, sirven para entender mejor un mainframe (de hecho, a mí me sirvieron para entender mejor el OS/400 aunque el AS/400 no sé si entra en la categoría "mainframe"). Pero es sorprendente que la palabra mainframe se pronuncie tan poco y que la gente, en general, no sepa ni de su existencia, cuando son los mainframes los que sostienen a las grandes organizaciones (son la informática estructural, que no coyuntural, de tales organizaciones).
#7 Si realmente tienes ganas de jugar con un MVS:
http://www.ibiblio.org/jmaynard/
#8: Con el editor del ISPF, el compilador (que sea PLI, please, nada de COBOL ;)), y un par o tres de JCLs preparados tienes suficiente Es lo bueno que tiene ese entorno: es tan espartano que con "una sabata i una espardenya" puedes ser muy productivo.
La próxima vez que vayáis al Corte Inglés, a algún banco o una aseguradora importante fijaros bien en el monitor y veréis que suele ser una pantalla en modo texto en emulación bajo windows. Detrás siempre lo importante, un buen equipo IBM, AS/400, iseries, etc...
Y lo firma un jefe de sistemas con equipos IBM iseries en la empresa y programando en COBOL/400 desde hace ya 20 años.
#22 EH ...esto es totalmente injusto... la maxima de " Si funciona no lo toques " es mia en #11 , o rectificáis u os voy a votar a todos como copia/plagio
Saludos
#27 a mí en la carrera tampoco me hablaron de mainframe específicamente, pero en arquitectura de computadores te dan una buena base para entender toda la base de funcionamiento del hardware. Es como estudiar ingenieria naval y centrarse en flotabilidad
C&P "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."
Buahahahaha ...haciendo amigos
Pero tiene razón , muchas de las maquinas centrales de bancos y servidores de cierta importancia global, siguen utilizando tecnologías poco geeks u consideradas obsoletas... pero como están curtidos en mil batallas y optimizados desde el primer 1 hasta el ultimo 0 no hay quien las tumbe... y siguen la maxima de " Si funciona...no lo to ques "
Saludos
El mito del software libre cayendo por su propio peso
un screenshot
Igual me pareció un comercial de IBM el artículo, pero muy bueno.
#23 El Corte Inglés utiliza IMS. Si te fijas bien verás que para acceder a algun formulario el cajero/cajera lanza un comando /FOR XXXXX
#17 #26 Más bien me huele al "Rational Developer for z", también conocido como RADz, y que es un comedor de recursos (de PC) insaciable. Con menos de 4G y un dual core de los buenos se arrastra... Aunque parezca mentira, es más ágil el TSO/ISPF que esas cositas modernas
//XXXXX JOB HOLA,CLASS=A
//PHOLA EXEC PGM=PUTPARM,PARM='Hello World!'
//OUTPARM DD SYSOUT=*
De los años 70???? Pues yo aquí sigo picando cobol en entorno mainframe...
Maravillosa serie. Cada dia aprendo mas. Sabia que estos mainfremes existian, pero pensaba que estaban poco menos que en un desván.
Os habeis fijado? procesadores a 4,4 Ghz!! 1,5 Tb de memoria en un solo sistema!!
Una pasada.
Me encanta la serie, a ver si sigue.
Los mainframes son unas bestias pardas. Pero el artículo adolece de la ibeemeitis clásica. HP y SUN, por ejemplo, tienen sistemas UNIX que cumplen las reglas de disponibilidad, rendimiento, virtualización y particionado, pago por uso y demanda... Un mainframe es mejor en algunas áreas, pero por mucha más pasta.
Lo de los discos depende también del almacenamiento, que no tiene nada que ver con el mainframe. Puedes pinchar una cabina EVA de HP, una EMC o una sun Storage a un Windows o un linux y disfrutar también de los discos que se mueren cada dos semanas sin que afecte al tiempo de disponibilidad.
Una gran empresa se plantea una nueva instalación de mainframe si necesita el gran gestor de transacciones que es la solución de IBM. Si es para otra necesidad, otras arquitecturas pueden suplir esa carencia a una fracción del coste.
#32 No tienes demasiada idea acerca de lo que dices.
En un mainframe puedes correr aplicaciones escritas en HLASM, COBOL, PLI, C, C++, PASCAL, java y prácticamente lo que te de la gana.
Se sigue programando en COBOL y PLI porque PARA LO QUE SIRVEN le dan mil vueltas a cosas más modernas. Para tratar transacciones y ficheros no necesitas ni punteros, ni clases, ni memoria dinámica, ni nada parecido.
No es cierto que el sistema te tire una transacción que lleva más de 2 segundos en máquina, Eso es configurable a nivel de transacción y de región de proceso. Lo que pasa es que para una transacción online 2 segundos de CPU son una ETERNIDAD. Yo tengo configurado mi IMS para que las tire a los 10 segundos, y es una exageración.
2 segundos de CPU son probablemente como 2 minutos en máquina. 2 minutos en los que tu transacción estará sujetando filas y registros que, probablemente, estén esperando otras transacciones. Si te llegan 2000 o 3000 por segundo enseguida tienes una cola de cojones.
Es la diferencia entre sistemas orientados al "query", y sistemas con actualización pesada.
Para que te hagas una idea: en mi curro se tuvo que mover una base de datos Oracle residente en un superdome HP que llevaba sólo información de sesión al backend DB2 porque cuando se le daba caña el Oracle se cortaba las venas.
Hay que haber visto trabajar a esos bichos para poder hablar con conocimiento de causa.
Donde yo trabajo se utilizan mainframes de IBM con programas COBOL para gestionar toda la información y lógica de negocio, y por encima máquinas UNIX corriendo aplicaciones web en JAVA para la capa de presentación.
Por el precio que tienen esos bichos ya pueden dar lo que dan, pero solo valen para lo que valen, para nada mas.
Es como tener un Formula 1, para ir al trabajo todos los dias, sencillamente no sirve.
La informática no ha progresado por los mainframes, fueron el principio y se han quedado con un nicho de mercado cada vez mas estrecho. Recuerdan los miniordenadores, desaparecieron, se los comieron lo microordenadores que los superaron en potencia y sobre todo en versatilidad.
Los mainframes actuales son el realidad cluster de micros, no tienen nada que ver con los monoprocesadores de antaño, aunque los emulen por compatibilidad. En el asunto de almacenamiento, tres cuartos de lo mismo, los discos duros de antaño, aquellas "lavadoras" han sido tecnológicamente superados y cualquiera que esté dispuesto a pagar lo suficiente consigue sistemas de almacenamiento muy alta disponibilidad, sin necesidad de que cuelguen de un mainframe.
¿Fault-tolerant?, otro concepto que se puede aplicar a muchos sistemas, no solo a los mainframes.
¿Caidas de sistemas?, claro que se caen, o ¿nadie ha tenido problemas con su banco porque el sistema esta caido?
De lo que si carecen los mainframes es de flexibilidad, Assembler y Cobol, ¿que se puede hacer con eso salvo mantener lo que ya funciona? como dicen un poco mas arriba. Si los PCs, solo soportaran eso ¿donde estariamos?
#16 no sabes de lo que hablas, pensar en adaptar a otro lenguaje la operativa de un banco puede ser la muerte de cualquier diseñador
#17 me parece que ya se para que banco trabajas..... puede ser que el bicho se llame Nemesis?
Creo que hay que aclarar que hay veces que la informatica es mas que graficos bonitos de colorines.
En micaso trabajo con i/series. Soporta, ademas del COBOL, C, Java ... Es servidor de aplicaciones. Puedo usar Apache o el suyo nativo. Lo puedo fragmentar i tener funcionando dentro un linux o un servidor windows. Puedo asignarle recursos de memoria y/o disco de forma dinamica.
Deespues de todo esto, los programas criticos funcionan en COBOL. Porque? Porque lo unico que tengo que demostrar es fiabilidad y seguridad. Esta funcionando 24 horas (descansa un par de horas los domingos para que se "limpie") y nunca me ha fallado.
Hay veces que la prioridad es la fiabilidad y disponibilidad 24/7 y eso solo se consigue con estos sistemas.
Tengo varios sistemas perifericos en linux que dan servicios. Estan programados en J2EE.
Quiero dormir tranquilo y mientras la empresa lo pague los sistemas criticos estaran en un mainframe (o mini mainframe).
#32 Tu argumento de que la informatica no ha evolucionado por los mainframes es falso. Es como si dijeras que los coches no han evolucionado por los Formula I porque no se les parecen.
Esto es como "Cuéntame" pero en informática
Meneo porque me encanta como escribe los artículos y ya había leido varios artículos anteriores.
#8: Por cierto: CICS o IMS? IMS/DB o DB2?
Los mainframeros también tenemos nuestras guerritas tipo vi/emacs
Realmente interesante y educativo. Sobretodo para los que no hemos podido "jugar" con un "bicho" de estos y nos tenemos que conformar con Unix, *BSD y GNU/Linux. También decir que los "big iron" de Sun e Ibm cada vez tienen más caracteristicas "heredadas" de los mainframes (LPar, cambio en caliente de componentes, larga compatibilidad binaria (Solaris), ....), aunque como bien dice la noticia los grandes bancos, aseguradoras, organismos públicos no van a meter su core business en un Unix, simplemente porque ha funcionado, funciona y funcionará. Es mejor seguir pagando una autentica fortuna a Mr Big Blue que gastarse otra fortuna en migrar y liarla parda.
Gran artículo, cualquiera que se autodenomine geek debe leerlo.
Gracias #1
#0 Muy interesante la serie, gracias!
#26 sssssssshhhhhhhhhhhhhhhh no se lo digas a nadie Pobre Nemesio....
#16 Tio, y que propones? una plataforma web 3.0 en la nube?
#30 PAÑOONNNN
Te voto positivo
#19, precisamente NO lo comparo. Pero las nuevas generaciones tendemos a pensar que Java y .Net son el chachipiruli 2.0
Luego hablamos de aplicaciones en la nube, hasta que GMAIL peta , imaginaros para un banco una aplicacion en la nube juas juas juas juas
increible... ¿Asi que ese mundo futurista existe?
A mi jefe cada dos por tres le salta una lagrimilla por los IBM RS/6000
¿Como me suscribo para recibir por mail los articulos de Macluskey y no todos los que se publican el el cedazo?
Aqui se explica como hacerlo pero no lo he conseguido:
http://eltamiz.com/elcedazo/como-funciona-el-cedazo/
¡¡VIVA EL PACBASE!! y "forever cobol".
A todo esto, el gran negocio que ha hecho IBM con los mainframe y con su licencia por uso.
#16 te crees en serio que un banco no migrara del COBOL porque "no le da la gana"? Por falta de dinero? Porque los resposables de informatica del banco no quieren complicarse la vida?