Tecnología, Internet y juegos
62 meneos
455 clics
Soy desarrollador profesional y sigo programando en COBOL

Soy desarrollador profesional y sigo programando en COBOL

En 2019 el lenguaje de programación COBOL ha cumplido 60 años. Y pese a que han ido apareciendo muchos lenguajes más modernos e intuitivos, COBOL sigue teniendo un peso muy importante en sectores tan importantes como la banca o la administración.

| etiquetas: lenguajes de programación , cobol , desarrolladores
46 16 4 K 351
46 16 4 K 351
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…   » ver todo el comentario
#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…   » ver todo el comentario
#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…   » ver todo el comentario
#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 xD
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... {0x1f62c}
Los hombres programan con 1 y 0 solamente
#3 Realmente, con el 9 sobra... :-P  media
#3 Los programadores de verdad usan mariposas.  media
#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…   » ver todo el comentario
#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...
comentarios cerrados

menéame