Portada
mis comunidades
otras secciones
#7:
#1
Documentados y archiconocidos .... ¡y una polla con flequilllo! Yo he trabajado con mainframe y ahí hay más mierda que en el palo de un gallinero, con módulos en ensamblador porque han perdido los fuentes, cosas sin documentar, legacies que nadie saben de donde provienen ni porqué están ahí y cientos de módulos que la gente no se atreve a tocar porque no sabe hasta donde llegan las repercusiones.
Si eso sigue de la mano de IBM es porque no se sale tan fácilmente de ahí.
Documentados y archiconocidos .... ¡y una polla con flequilllo! Yo he trabajado con mainframe y ahí hay más mierda que en el palo de un gallinero, con módulos en ensamblador porque han perdido los fuentes, cosas sin documentar, legacies que nadie saben de donde provienen ni porqué están ahí y cientos de módulos que la gente no se atreve a tocar porque no sabe hasta donde llegan las repercusiones.
Si eso sigue de la mano de IBM es porque no se sale tan fácilmente de ahí.
#1:
Funciona, es simple y en estos puntos críticos de banca y Administración es claramente preferible el mantenimiento de sistemas ampliamente documentados y archiconocidos por sus operadores y desarrolladores tras décadas de uso que empantanarse en costosísimas migraciones a salvajadas en Java o Python (con suerte) de la mano de cualquier cárnica o empresa de servicios que, podemos estar segurísimos de ello, acabaría en un absoluto desastre irremediable y la pérdida de decenas o cientos de millones de euros.
#10:
#1 Si las empresas no han migrado fuera de los mainframes es porque es un "vendor lock-in" de libro que se sacó de la manga IBM y salir de ahí es un coste elevado porque nadie quiere jugársela a migrar los montones de comportamientos que se han ido parcheando sobre el código durante décadas, que eso de que está ampliamente documentado va a ser que no en muchos casos como dice #7.
Sobre la criticidad, ejemplo práctico, coge un sistema similar pero con requerimientos mucho más estrictos que el banco estándar, las bolsas mundiales, Wall Street migró hace años a sistemas Unix/Linux y lenguajes de programación modernos desde los mainframes que utilizaba por coste y rendimiento, y si falla algo en una bolsa si que puedes jugarte millones en cuestión de unos pocos segundos o incluso menos si vas a cosas como las transacciones de alta frecuencia, así que está más que demostrado que se pueden usar sistemas estándar para cosas críticas.
Algo parecido a los mainframes más actual es SAP, salir de un ERP como SAP es un infierno porque suelen ser sistemas que se enganchan por todas las partes de la empresa, desarrollados según iba saliendo la necesidad con parches sobre parches y que acaban siendo un caos donde lo mejor es no tocar porque no se sabe muy bien como funciona todo.
Sobre la criticidad, ejemplo práctico, coge un sistema similar pero con requerimientos mucho más estrictos que el banco estándar, las bolsas mundiales, Wall Street migró hace años a sistemas Unix/Linux y lenguajes de programación modernos desde los mainframes que utilizaba por coste y rendimiento, y si falla algo en una bolsa si que puedes jugarte millones en cuestión de unos pocos segundos o incluso menos si vas a cosas como las transacciones de alta frecuencia, así que está más que demostrado que se pueden usar sistemas estándar para cosas críticas.
Algo parecido a los mainframes más actual es SAP, salir de un ERP como SAP es un infierno porque suelen ser sistemas que se enganchan por todas las partes de la empresa, desarrollados según iba saliendo la necesidad con parches sobre parches y que acaban siendo un caos donde lo mejor es no tocar porque no se sabe muy bien como funciona todo.
Comentarios
Funciona, es simple y en estos puntos críticos de banca y Administración es claramente preferible el mantenimiento de sistemas ampliamente documentados y archiconocidos por sus operadores y desarrolladores tras décadas de uso que empantanarse en costosísimas migraciones a salvajadas en Java o Python (con suerte) de la mano de cualquier cárnica o empresa de servicios que, podemos estar segurísimos de ello, acabaría en un absoluto desastre irremediable y la pérdida de decenas o cientos de millones de euros.
#1
Documentados y archiconocidos .... ¡y una polla con flequilllo! Yo he trabajado con mainframe y ahí hay más mierda que en el palo de un gallinero, con módulos en ensamblador porque han perdido los fuentes, cosas sin documentar, legacies que nadie saben de donde provienen ni porqué están ahí y cientos de módulos que la gente no se atreve a tocar porque no sabe hasta donde llegan las repercusiones.
Si eso sigue de la mano de IBM es porque no se sale tan fácilmente de ahí.
#1 Si las empresas no han migrado fuera de los mainframes es porque es un "vendor lock-in" de libro que se sacó de la manga IBM y salir de ahí es un coste elevado porque nadie quiere jugársela a migrar los montones de comportamientos que se han ido parcheando sobre el código durante décadas, que eso de que está ampliamente documentado va a ser que no en muchos casos como dice #7.
Sobre la criticidad, ejemplo práctico, coge un sistema similar pero con requerimientos mucho más estrictos que el banco estándar, las bolsas mundiales, Wall Street migró hace años a sistemas Unix/Linux y lenguajes de programación modernos desde los mainframes que utilizaba por coste y rendimiento, y si falla algo en una bolsa si que puedes jugarte millones en cuestión de unos pocos segundos o incluso menos si vas a cosas como las transacciones de alta frecuencia, así que está más que demostrado que se pueden usar sistemas estándar para cosas críticas.
Algo parecido a los mainframes más actual es SAP, salir de un ERP como SAP es un infierno porque suelen ser sistemas que se enganchan por todas las partes de la empresa, desarrollados según iba saliendo la necesidad con parches sobre parches y que acaban siendo un caos donde lo mejor es no tocar porque no se sabe muy bien como funciona todo.
#10 Sí se pueden usar sistemas estándar, "relativamente" estándar porque no valen unos servidores baratitos montados con ethernet gigabit y ya está...
#11 hasta que un día una cpu se pete y veas como en mainframe, ojo! es un pastoncio que cobras de sobras a tus clientes que fries a comisiones o paga papa ESTADO, se cambia en caliente y sin parar, reemplazasas cualquier componente, hasta el más critico, porque tienes redundancia (y garantia contractual) hasta en las muelas.
la confiabilidad del mainframe se mide en décadas, no semanas o días.
sin ser IBMero (fuí más fan de Bull)
"el índice de disponibilidad del hardware para un zSeries en clúster llega al 99,999%, lo cual equivaldría a menos de cinco minutos de indisponibilidad de sistemas por año."
y no se paran, ese es el peor escenario como el sufrido en el centro de datos de Banco Zaragozano hace un montón de años. inundación + terremoto creo.
#10
Respecto a SAP (otro agujero negro guapo) en Telefonica se decía que una vez lo adaptaron tanto a sus “particularidades” que a la hora de actualizar la versión pasaron las de Caín, tardando un huevo y gastando un mogollón de pasta.
#12 Yo he visto a hombres llorar como niños trabajando con SAP.
#13 y ERES a malsanva antes de reconocer su cagada por el CTO al que se lo colaron por un powerpoint,
#10 #12 #13 Como desarrollador de SAP:
SAP es lo que es, no es ningun infierno y de hecho el R3 es un carajal bastante bien montado pal tamaño que tiene.
Estais hablando de un ERP completo que abarca desde finanzas hasta almacen, intefaseados todos sus modulos, lo controla absolutamente todo y lo hace bastante bien. La cometencia en esto ni está ni se la espera.
Su principal virtud que es esa es tambien su principal defecto, es tan monstruosamente gordo que dominarlo entero es prácticamente inviable, está documentado y además el código es medianamente legible, pero si quieres saber como funciona todo igual no te da la vida, por lo que la gente suele especializarse en modulos especificos, en mi caso tengo idea de como corre finazas contabilidad compras y almacen más o menos, y a duras penas.
Cuando tu tienes un sistema que igual empezar a pillar callo con el te cuesta un minimo 5 años de tu vida dedicado 8h 5 dias a la semana a mirar locuras, un sistema cerrado, que no se estudia en la universidad ni tienes acceso a cacharrear con el de manera comoda en casa (por la propia naturaleza del mismo, nadie tiene un almacen logistico con multiples nodos y diques secos, sistemas de radiofrecuencia y controles de stockaje montado en su salon) pues resulta que gente que puche del tema hay poca, y cuando hay poca gente... esta tiene la mala costumbre de cobrar bien.
La problematica con SAP no es que el sistema funcione mal, la problematica con SAP es que es complejo encontrar a gente que realmente no venda humo y sepa hacer la O con un canuto
#12 SAP? vade retro!!!
#18 SAP está sobrevalorado. Es una basura cuadriculada alemana.
#10 Wall street usará unix/linux y lenguajes modernos para bases de datos y visualización web, pero la base va sobre VHDL y FPGA como Nasdaq y su TotalView-ITCH, y así van las máquinas que estén suscritas.
#7 Si no se sale es porque la alternativa es exactamente como lo he dicho: migración masiva a sistemas nuevos hechos desde cero en un lenguaje moderno, con todas las implicaciones en tiempo, dinero y caídas del servicio que ello implica.
Ante esos escenarios, lo lógico y lo sensato es seguir con lo que se tiene y conoce, en lugar de cambiar sólo por el hecho de cambiar. Si migrar fuera fácil y barato, hace 20 años que se habría hecho. No se hace porque es incertidumbre y gasto de dinero injustificable desde el punto de vista operativo. Fin, no hay más.
#7 te voto positivo sobre todo por el flequillo ese , que me ha hecho mucha gracia. (también por el resto)
Desde que estudie COBOL me decían que iba a desaparecer.
#20 al igual que IPv4
farragoso de escribir pero sumamente eficiente, estuve 25 años con él con los cacharrazos de Bull en banca, y ni me puedo llegar a imaginar lo que puede "zumbar" ahora en rendimiento con las mainframes con cpus modernas.
practicamente es un lenguaje de transferencias de memoria (las cribadas MOVES, el 99% de cualquier código COBOL)
#2
Cualquier operador de asignación es básicamente un movimiento de memoria, lo que pasa es que en lugar de MOV escribimos “=“
#8 no solo eso, = expresion contra ancho fijo, primero compute y luego si eso MOVE, dimensinado estricto, a nivel de compilador es un corsé imbatible para mi.
zapatero a tus zapatos estricto, pero un buel cobolosaurio en un entorno corporativo y normalizado(lo que ahora llamariamos framework), te hace un código eficiente sin ni quererlo. de Cobol pasé a ensamblador de mainframe y esa cpu parece que se había diseñado a medida del cobol. es como si hubieran hecho una x86 para un lenguaje espécifico.
RPG es el único que se me atragantó y lo pude esquivar, a pesar de los sueldazos nicho. y Así se muera.
El COBOL morirá cuando lo hagan las entidades bancarias que lo usaron.
Nunca se había retirado tanto software como cuando se dio el baile de fusiones durante el crack del 2007.
#21 ya faltó menos... 😬
Duplicada: Soy desarrollador profesional y sigo programando en COBOL
Soy desarrollador profesional y sigo programando e...
xataka.comLos hombres programan con 1 y 0 solamente
#3 Realmente, con el 9 sobra...
#3 Los programadores de verdad usan mariposas.
#3 Menudo pijo. En mi empresa solo nos dan 0s.
#9 me has sacado una carcajada en un mal día, gracias!!!!
Artículo xatacoso de relleno que sale cada 6 meses. No he visto al autor (a) pero creo que sé quien va a ser...
Muy bien, sigue desarrollándote...no hay nada como el crecimiento personal....
Tengo un tio que esta cerca de la jubilacion y tiene trabajo de cobol a punta pala, la gente joven no lo quiere aprender y los bancos no tienen la capacidad para quitarselo de encima. Recuerdo en una empresa que tuve que hacer una aplicacion para comprobar cuantas transacciones por segundo podia hacer una maquina, y basicamente era una aplicacion en C con un wrap a Cobol. El programa simplemente linkaba con una applicacion cobol que abria un terminal (un cajero). Cuando le pregunte a un desarrollador de cobol si me podia enseñar el diagrama de llamadas de la applicacion que abria el cajero alucine con la complejidad que tenia, total que si los bancos no pueden quitar cobol por que nadie sabe que hace el programa X, y no hay recursos para resescribirlo en Java por ejemplo.
#22 También hay que decir que reescribir una cosa que funciona sólo por cambiar de lenguaje es una gilipollez, y si el lenguaje de destino es Java a estas alturas todavía más.
El plan no puede ser coger un montón de mierda y pintarla de otro color.
#24 reescribir por reescribir es una gilipollez como has dicho, de echo, recuerdo que el framework de microfocus te permitia hacer wrappers a codigo en cobol con lo que estaba integrado perfectamente.
El cobol será todo lo estable que queráis pero la forma en la que se usa en los bancos es una basura.
Esto va a sonar peliculero pero trabaje con una subcontrata en un banco durante 1 año y encontré un fallo de seguridad tan gordo que rozaba lo absurdo: tenía todos los medios a mi alcance para poder hacer cualquier operacion bancaria, crear cuentas, ingresar pasta, transferirlas, etc. Directamente no existía ningún control acerca de la autenticidad de las peticiones que procesaba el host principal.
Hace casi diez años de esto y a día de hoy seguro que sigue igual...