En el año 1959 el Departamento de Defensa de Estados Unidos junto con fabricantes tecnológicos de la época, crearon un lenguaje de programación, llamado COBOL...
#19#1 Cada vez que escucho: "No encontramos (ponga aquí el profesional que desee)" o "Casi no hay (ponga aquí profesional que desee)". Lo que quieren decir en realidad es: "No encontramos (profesional mencionado) que quiera aceptar salarios de miseria" o "Casi no hay (profesional mencionado) que quiera trabajar en condiciones deplorables sin quejarse".
Hace tiempo vi una oferta de Infojobs (sí, de una empresa lider en el sector) donde buscaban gente programar en Cobol y si no sabías te formaban. Creo que había cerca de 1000 personas inscritas.
El problema no es migrarlo, lo que dice el artículo ya había empresas que lo ofrecían antes, solo que ahora se ha añadido lo de IA. Ni siquiera que tenga que ser revisado y ajustado posteriormente por programadores. El principal problema es asegurar que el código nuevo hace exactamente lo mismo que el código en COBOL y ahí, teniendo en cuenta que se usa en empresas que mueven mucho dinero como bancos y aseguradoras, ya no es tan fácil que haya alguien que se moje y certifique que funciona igual porque como dicen nadie sabe exactamente todo lo que hacen, y eso incluye a la gente de negocio no solo a los desarrolladores.
#1 Aprender un lenguaje para trabajar no es conocer la sintaxis básica, sino las herramientas más usadas, los problemas habituales,... y en caso como estos, los entornos donde se usan.
A mí si me sueltan 10K/mes y me dejan trabajar desde algún puebloh barato de la España Vaciada, me pongo a estudiar cobol como un loco.
Por lo demás, si cobol, c, unix, etc. siguen en el candelero desde hace décadas, seguro que ya es difícil encontrar algo mejor, por mucho empeño que pongan.
#1 cualquiera que tenga más de 50 años seguro que ha pasado un tiempo trabajando en Cobol.
Ya no me acuerdo mucho, la verdad, pero estuve unos 8 años trabajando en Cobol para una aseguradora, no creo que me costase mucho volver a cogerle el tranquillo.
Pero era aburrido de narices, así que, si me quieren, solo es cuestión de poner pasta sobre la mesa.
Creo que el problema no es solo el Cobol, es el sistema ALREDEDOR del Cobol.
Un IBM 3090 está pensado para leer de muchas fuentes de datos a la vez y procesarlas mientras las leen, un ordenador de sobremesa actual tiene muchisima más potencia… pero no está pensado para trabajar de esta forma, por lo que se deben cambiar todos los procedimientos y la forma de trabajar con los datos, y eso es lo complicado de la migración.
Tratar de conseguir exactamente los mismos resultados a nivel de centimos haciendo cosas muy, pero que muy, distintas, no es nada fácil.
#1 Cada vez que escucho: "No encontramos (ponga aquí el profesional que desee)" o "Casi no hay (ponga aquí profesional que desee)". Lo que quieren decir en realidad es: "No encontramos (profesional mencionado) que quiera aceptar salarios de miseria" o "Casi no hay (profesional mencionado) que quiera trabajar en condiciones deplorables sin quejarse".
#1#11 Y mas un lenguaje como COBOL donde el resto del ecosistema es muy diferente. IBM z/OS, VSAM, CICS Transaction Server for z/OS, JCL, ISPF, ..... y un monton de mierdas mas que casi no se usan y casi nadie sabe.
Yo en su dia sabia bastante ... dios me guarde de volver a usar nada de eso antes de retirarme.
#7 Ademas te tienes que comer una fase de testeo sin gente que entienda ni el codigo ni lo requisitos de negocio ... prefiero hacer malabares con motosierras, es mas seguro.
Migrar código de hace sesenta años de una forma de pensar diferente como Cobol es tan caro que seguramente estén contratando y formando programadores en ese lenguaje.
Si es caro de migrar y tiene sesenta años, no es la aplicación de sastrerías martinez. Es una empresa donde hay dinero. ¿Para qué migrar cuando puedes contratar gente o incluso formarles?
No, la verdad es que no me acabo de creer la noticia.
El problema no es COBOL, es un lenguaje sencillo pensado para que cualquiera pudiera programarlo. La mayoría de lenguajes
actuales le da mil vuelas en complejidad y tienen curvas de aprendizaje mucho más empinadas.
El problema es que llevan funcionando muchos años y nadie sabe al 100% funcionalmente cómo lo hacen.
Es decir, que puedes aprender todos los secretos de COBOL en un par de semanas, pero luego a ver quién es el guapo que le mete mano a un sistema de seguridad social de un departamento de EE.UU que lleva funcionando desde hace más de 40 años.
#11 Por eso he hablado de un desarrollador con experiencia. Alguien que lleva años en el mundillo del desarrollo se aprende la sintaxis en una tarde, y sabe perfectamente que eso es lo de menos y como tu bien dices toca estudiar y documentarse.
El problema que tienen los de RRHH cuando buscan a alguien para este puesto es que piensan que o importante es encontrar a alguien que lleve años en ese lenguaje concreto cuando lo que realmente importa es saber de estructuras, arquitecturas y entornos.
#1 realmente por cobol ya pagan bién... Pero el problema realmente no es cobol (aunque parezca asm lo veo más tipo Basic) si no entender lo que hay programado pero de lo que no tenemos documentación y sibre todo entender la mentalidad de l aque salian las chapuzas, como salen ahora... Sigo encontrandome ifs del estilo "if (true) {" porque les da pereza eliminar los elses.....
#18 ¿3090? Me parece que hace más de 40 años que no estás cerca de un mainframe. La serie 30xx es del año la polca. El 3090 ya estaba en producción en la década de los '80 (me tocó estrenar alguno). El sucesor, la familia Z, ahora ya va por la generación z16, con z/OS, o z/VM o hasta Linux... He migrado varias cargas desde Z a distribuidos. Alguna con cobol. La mayoría de las veces con resultados bastante nefastos. En la práctica fueron más caros de mantener, de explotar y con muchas más incidencias, que el original en mainframe. Pero, sí; coincido con lo último que dices, IMHO no es que se no se puede hacer desaparecer al COBOL; es que, para determinadas cargas, sigue sin haber algo mejor...
#39 Un banco sí es algo especial. Para empezar, están sujetos a leyes muy particulares en cuanto a qué deben hacer en sus sistemas. Pero eso es lo de menos. Siempre tienes que cambiar 7 cosas más... Si quitas una carga COBOL de un mainframe, que lleva años funcionando perfectamente, es para bajarla a distribuidos porque pretendes reducir costes... y de poco te sirve bajar el aplicativo y dejarte arriba el IMS, el CICS o el DB2 para atacarlo por TCP/IP (con todos los MIPS de más que se llevan esos procesos de red == $$$$$). Al final, lo normal es que acabes con 20 máquinas Unix dándose backup unas a otras en las que las actualizaciones son auténticas pesadillas y, dónde antes tenías a 4 Ingenieros de Sistemas muy bien pagados, ahora tienes a 10 seniors, 20 juniors y un contrato AM de mantenimiento de software drenándote la cartera...
#10 En un importante banco Español (y mundial) se intento inventariar todo el software y fue imposible. Habia un 40% que nadie sabia exactamente que hacia pero que pertenecia al core del banco.
#18 Que un ordenador de sobremesa actual tiene más potencia que un mainframe... solo indica tu nivel de desconocimiento, sorry pero es la realidad, aunque como chiste es bueno eh.
Estas hablando de sistemas con varios procesadores ubicados en sus propias tarjetas funcionando en paralelo con un sistema operativo capaz de soportar cambios en caliente, cientos de personas trabajando, y aceptación de millones de datos en tiempo real, y soportar todo eso la vez, además, resistente a cualquier avería y capaz de seguir funcionando mientras se arregla insitu sin desconectar nada.... y garantizado el funcionamento el 365 días al año.
#26 Hace 20 años Coritel (de Accenture, ahora no sé cómo se llama) estaba formando programadores de COBOL en plan churrería. Un curso de un mes y a funcionar. El 90% caían rápido, eso sí.
#1 En realidad hay montones de desarrolladores de COBOL. Estos artículos están escritos desde el más absoluto desconocimiento de la materia.
Las grandes consultoras (NTT Data, SopraSteria, Accenture, etc) lanzan periódicamente programas de becas pagadas (unos 1000 EUR/mes durante 9 meses) en los que te enseñan desde cero a programar en COBOL y mainframe. Al finalizar, salvo que seas un cazurro absoluto, suelen ofrecerte quedarte en plantilla. Obviamente, no se empieza cobrando sueldo forocochero pero se evoluciona rápido y se puede alcanzar un sueldo bastante bastante decente en un par de años. Teniendo en cuenta que aceptan a cualquiera (recuerdo ingenieros industriales, químicos, licenciados en Historia y hasta abogados), están dando una oportunidad para iniciarse en IT a gente que de otra manera no tendría entrada fácil.
#19 No, en el caso de COBOL no se trata de "pay them more".
Se trata de que es un nicho laboral: los clientes son grandes empresas que tienen su IT, incluyendo desarrollo, externalizado a grandes consultoras.
Tu crecimiento laboral está limitado a pasar de NTT Data a Sopra, de Sopra a Accenture, de Accenture a Tata, etc. Vas cambiando de cliente y ganando más dinero pero mucha gente, irónicamente*, tiene una sensación de inseguridad, de que el mainframe va a morir mañana y se van a quedar en la calle porque aunque son clientes y consultoras grandes, son pocas consultoras. Por ese motivo, un alto porcentaje de la gente que se inició el COBOL con las becas que comento en #51 se pasan a otra tecnología (.NET, frontend, Go, Kubernetes, AWS/Azure, etc) al cabo de 5 años más o menos.
* Digo "irónicamente" porque personalmente considero que antes morirá Kubernetes que el mainframe.
#14 Tengo un conocido que trabaja con mainframes y COBOL para banca en la City. Gana mucha pasta y no tiene hijos (sí homo), así que cada 3-4 años se pilla 6-12 meses sabáticos. Lleva 25 años así.
#38 Conozco varios casos de directores de IT y CIOs que prometieron que cuando ellos mandaran, se iban a cargar el mainframe, que eso era una cosa antigua... y nada más lejos de la realidad: cuando vieron la fiabilidad, rendimiento y eficiencia del mainframe, han doblado su apuesta por él. La redundancia del mainframe les da tranquiliadad absoluta, y el alto rendimiento por la cercanía entre computación y datos lo hace muy eficiente.
Tengo clientes que han migrado de Kubernetes en x86-64 a Kubernetes en mainframe (!). Obviamente, hablo de clientes grandes, esto no es para Bar Paco ni para Talleres Juan.
#34 Cuidadin con cobol que tiene truquitos de sintaxis y cosas raras.
Eestoy pensando como las condiciones de los batch de MSDOS que tiene que tener el expacio e indexado justo que sino lo les gusta, y no recibes ningun error solo que nunca se da la condicion.
#36
Y lo de progamar todo sin estructuras de datos. en.wikipedia.org/wiki/Jackson_structured_programming
Ironicamente esto de lo que se avisaba en 1975 lo estoy viendo en programas en python, que a la penya el gusta aplanar estructuras de datos. y pasar todos los parametros en un array. Verdadera POO Programacion orientada al ojete.
Basicamente yo me dedico a pasar programas de python a c# cuando el programador de python que creo el programa se va de la empresa y los developers de python que vienen despues no son capaces de mantenerlo.
#39 Lo de que el lenguaje no el el problema no es cierto.Te puedo presentar un codigo que vale para python y c# y funciona de forma totalmente diferente ya que python intenta forzar que tenga sentido y en ese caso lo consideraba booleano.
El python que me suelen pasar a migrar a c#, despues de que sucesivos developers python que no fueron el orginal huyan de ese projecto es una mierda. En un lenguaje fuertemente typado es mas dificil hacer mierdas.
#21 Y además no creo que haya muchos emuladores de estas plataformas. Yo trabajé bastante tiempo con DB2 sobre OS/390 y no creo que haya ningún sitio para aprender esto, ni CICS, ni muchas otras cosas del viejo mundo mainframe.
#52 Personalmente, y como viejuno que soy, le he cogido manía a las moderneces como Kubernetes, Terraform, Ansible, etc. Me parecen una mierdaza fuera de control.
#33 Pues ese es el tema, que obvian todos estos pastiches de copia pega. El problema no es aprender Cobol, que lo aprende hasta un mono porque son 4 instrucciones contadas. El problema es conocer del negocio, las aplicaciones que están sobre Cobol, las estructuras de datos, cual es el flujo del dinero y por dónde va. Y eso no se aprende en 4 días, sino que se sabe cuando uno lleva en la empresa un porrón de años y se conoce todos los procesos y workflows. Pero eso no te lo va a contar ningún medio Xataka, claro, ellos ya están para otra cosa.
#26 Es sensacionalista como una casa y un clickbait de libro. Pero claro, la sacan cada 2x3 porque saben que alguien va a picar y porque no falta quien menee estas cosas. Van a tiro hecho.
#52 Lo de externalizar ahora se esta viendo que fue una idea "genial".
Gente que conocía el negocio a fondo, a tomar por culo y le damos la informática a una cárnica de mierda consultora externa, que ya sabemos como trabajan.
Pues ahora no cuentan con gente que conozca a fondo del negocio ni el COBOL.
#1 Esque la lógica de las aplicaciones en COBOL (que la sintaxis la lee casi hasta un niño), no tiene nada que ver con cualquier metodología de progamación actual.
Verás, la mayoría de veces programar tiene más de entender el negocio que estás programando y los fundamentos de su CORE que de saber poner ifs, loops o return. Al fin y al cabo, un lenguaje de programación, es un idioma, que se puede comparar a ladrillos... y en cambio, con ese mismo ladrillo, lo mismo construyes una mansión, una catedral, una casa en el bosque o un rascacielos.
Pues aquí lo mismo... esto va de "arquitectura", y la arquitectura de aplicaciones implementadas en COBOL aparte de prehistóricas y nula documentación... en un mundo financiero que permite pràcticamente ningún error... es terrible, letal, poner a alguien que no comprende las repercusiones de poner o no un 0 o un null en un campo... puede cambiar absolutamente todo y tardar meses en poder depurar dónde està el error.
Vamos, es un problema de prehistoria funcionando en el siglo XXI, nadie se atreve a apagar dichos servidores, porque no hay equivalente que los reemplace, y a su vez, necesitan adaptar los cambios que imponen las legislaciones y leyes... en fin, un caos.
#19 No es eso. El tema es que los sistemas en COBOL, son nichos muy pequeños.
Son programas que llevan tiempo sin recibir actualizaciones, al menos en sus capas más interiores. Llevan decadas contratando desarrolladores para llevar algunas funcionalidades a otros entornos. Pero eso es la periferia del programa. El núcleo no se toca y si en algún momento alguien decide una partida presupuestaria para hacer cambios será un sprint enormey largo para migrar a C++, Java o alguna cosa más moderna lo que hay e independizarlo del mainframe y su ecosistema: CICS, MQSeries, DB2,ME series. En algún momento parecía que esas tecnologías emergerían en UNIX. De hecho están soportadas en AIX, pero sigue siendo ser cauitivo de IBM, de su hierro y de su sistema operativo.
Yo no puedo hablar por los demás, pero no tengo ganas de ponerme a destinar como funciona un sistema arcano para re implementarlo en una arquitectura moderna, porque no es nada estimulante.
Un banco no entiende por qué tiene que pagar otro desarrolló para tardar años en tener que ya hace lo mismo que hace el programa que tiene y que está amortizado. El jefe de sistemas si lo entiende, pero los responsables de negocio no quieren pasar por ahí.
Conón profesional no tengo ganas de formarme para un proyecto que es un nicho diminuto y que parece que va a ser cancelado en cualquier momento. O no se o tenemos éxito y finaliza y tampoco nos necesitan.
#64 Tienes razón en su bajo rendimiento pero respecto al mantenimiento discrepo profundamente. ¡Todo lo contrario!
Python aunque es de tipado dinámico también es de tipado fuerte. Y es, sin lugar a dudas, el lenguaje más minimalista y legible de todos.
Por lo general, Python hace en 5 líneas lo que otros hacen en 10. Y está enfocado para no dar rienda suelta a la imaginación en las implementaciones. En Python las cosas solo se hacen de una manera (o al menos esa es la idea zen). Además obliga a intentar correctamente. ¿Qué más quieres?
#1 Si quisieran pagar bien a un desarrollador bueno para que primero aprenda Cobol a un nivel de experto (un añito o dos como mínimo trabajando a saco), luego aprenda la aplicación sobre la que tiene que trabajar (a lo mejor medio año más), y luego haga los cambios que se necesitasen con todas las pruebas necesarias para asegurarse de que todo está bien y de que ningún banco va a petar...
Antes que eso preferirían pagar a un buen desarrollador de <lenguaje moderno> que reescribiera la aplicación desde cero.
Cualquiera de las dos opciones es mucho dinero que prefieren quedarse para bonuses de esos.
Pues aquí alguien que sigue desarrollando en COBOL, y a mucha honra.
Desarrollo en un ERP de RRHH para empresas grandes (>5000 empleados). Nada he visto más rápido para gestionar un proceso batch grande y complejo como un cálculo de nómina. Llevo unos 7000 empleados en esa aplicación, y una nómina completa tarda unos 10 minutos (contando que más de la mitad del tiempo se lo come la base de datos con inserts y deletes)
La empresa editora nos ha dicho que quieren ir quitando COBOL como el core de la aplicación (porque nadie quiere desarrollar en ese lenguaje) pero ya asumen que de lo último (2030) que van a plantearse quitarlo es el batch de la nómina porque no encuentran nada tan rápido y eficiente
En definitiva, llevo 15 años oyendo que COBOL está muerto, y lo cierto es que antes acariciaré yo el trigo
COBOL es un lenguaje diseñado para ser accesible a personas sin transfondo técnico. Que la gente no sepa COBOL nunca ha sido un problema. La pasta tampoco está en saber programar, está en el mantenimiento: depurar una cadena de llamadas entre decenas de módulos, optimizar procesos batch o la latencia online, etc. Y para esto hace falta saber de muchas cosas más que COBOL.
#38 Te puedo asegurar que en los 90 (cuando me dedicaba al Cobol) trabajabamos con IBM 3090... del que incluso tuve que tocar el código máquina para un proyecto.
#63 te entiendo perfectamente. Ojo, solucionan un problema y lo solucionan muy bien. El caso es que probablemente no solucionan nuestro problema, sino el de Google, Meta, Amazon... pero como están de moda se aplican donde no toca.
No necesitas Kubernetes para una aplicación monolítica de intranet con 1000 usuarios diarios (ni 10000, ni 100000...) Tampoco necesitas una arquitectura de microservicios.
Esa es la realidad.
#14 lo relata estupendamente.
Pay them more.
#FreeAssange
Por lo demás, si cobol, c, unix, etc. siguen en el candelero desde hace décadas, seguro que ya es difícil encontrar algo mejor, por mucho empeño que pongan.
www.casadellibro.com/libro-curso-de-programacion-rm-cobol-85/978847897
185€ ahora de segunda mano!! Con que alegría lo tiré a la basura!! jajaja
Ya no me acuerdo mucho, la verdad, pero estuve unos 8 años trabajando en Cobol para una aseguradora, no creo que me costase mucho volver a cogerle el tranquillo.
Pero era aburrido de narices, así que, si me quieren, solo es cuestión de poner pasta sobre la mesa.
Un IBM 3090 está pensado para leer de muchas fuentes de datos a la vez y procesarlas mientras las leen, un ordenador de sobremesa actual tiene muchisima más potencia… pero no está pensado para trabajar de esta forma, por lo que se deben cambiar todos los procedimientos y la forma de trabajar con los datos, y eso es lo complicado de la migración.
Tratar de conseguir exactamente los mismos resultados a nivel de centimos haciendo cosas muy, pero que muy, distintas, no es nada fácil.
Esa es la realidad.
#14 lo relata estupendamente.
Pay them more.
#FreeAssange
Yo en su dia sabia bastante ... dios me guarde de volver a usar nada de eso antes de retirarme.
Migrar código de hace sesenta años de una forma de pensar diferente como Cobol es tan caro que seguramente estén contratando y formando programadores en ese lenguaje.
Si es caro de migrar y tiene sesenta años, no es la aplicación de sastrerías martinez. Es una empresa donde hay dinero. ¿Para qué migrar cuando puedes contratar gente o incluso formarles?
No, la verdad es que no me acabo de creer la noticia.
actuales le da mil vuelas en complejidad y tienen curvas de aprendizaje mucho más empinadas.
El problema es que llevan funcionando muchos años y nadie sabe al 100% funcionalmente cómo lo hacen.
Es decir, que puedes aprender todos los secretos de COBOL en un par de semanas, pero luego a ver quién es el guapo que le mete mano a un sistema de seguridad social de un departamento de EE.UU que lleva funcionando desde hace más de 40 años.
El problema que tienen los de RRHH cuando buscan a alguien para este puesto es que piensan que o importante es encontrar a alguien que lleve años en ese lenguaje concreto cuando lo que realmente importa es saber de estructuras, arquitecturas y entornos.
Esa es la oferta en Freelance.com
El lenguaje rara vez es el problema.
Estas hablando de sistemas con varios procesadores ubicados en sus propias tarjetas funcionando en paralelo con un sistema operativo capaz de soportar cambios en caliente, cientos de personas trabajando, y aceptación de millones de datos en tiempo real, y soportar todo eso la vez, además, resistente a cualquier avería y capaz de seguir funcionando mientras se arregla insitu sin desconectar nada.... y garantizado el funcionamento el 365 días al año.
"...es que así es más moderno y blablabla" ---> Palabrería de Power Point, no hacer caso.
Las grandes consultoras (NTT Data, SopraSteria, Accenture, etc) lanzan periódicamente programas de becas pagadas (unos 1000 EUR/mes durante 9 meses) en los que te enseñan desde cero a programar en COBOL y mainframe. Al finalizar, salvo que seas un cazurro absoluto, suelen ofrecerte quedarte en plantilla. Obviamente, no se empieza cobrando sueldo forocochero pero se evoluciona rápido y se puede alcanzar un sueldo bastante bastante decente en un par de años. Teniendo en cuenta que aceptan a cualquiera (recuerdo ingenieros industriales, químicos, licenciados en Historia y hasta abogados), están dando una oportunidad para iniciarse en IT a gente que de otra manera no tendría entrada fácil.
Se trata de que es un nicho laboral: los clientes son grandes empresas que tienen su IT, incluyendo desarrollo, externalizado a grandes consultoras.
Tu crecimiento laboral está limitado a pasar de NTT Data a Sopra, de Sopra a Accenture, de Accenture a Tata, etc. Vas cambiando de cliente y ganando más dinero pero mucha gente, irónicamente*, tiene una sensación de inseguridad, de que el mainframe va a morir mañana y se van a quedar en la calle porque aunque son clientes y consultoras grandes, son pocas consultoras. Por ese motivo, un alto porcentaje de la gente que se inició el COBOL con las becas que comento en #51 se pasan a otra tecnología (.NET, frontend, Go, Kubernetes, AWS/Azure, etc) al cabo de 5 años más o menos.
* Digo "irónicamente" porque personalmente considero que antes morirá Kubernetes que el mainframe.
Tengo clientes que han migrado de Kubernetes en x86-64 a Kubernetes en mainframe (!). Obviamente, hablo de clientes grandes, esto no es para Bar Paco ni para Talleres Juan.
Eestoy pensando como las condiciones de los batch de MSDOS que tiene que tener el expacio e indexado justo que sino lo les gusta, y no recibes ningun error solo que nunca se da la condicion.
Y lo de progamar todo sin estructuras de datos.
en.wikipedia.org/wiki/Jackson_structured_programming
Ironicamente esto de lo que se avisaba en 1975 lo estoy viendo en programas en python, que a la penya el gusta aplanar estructuras de datos. y pasar todos los parametros en un array. Verdadera POO Programacion orientada al ojete.
Basicamente yo me dedico a pasar programas de python a c# cuando el programador de python que creo el programa se va de la empresa y los developers de python que vienen despues no son capaces de mantenerlo.
El python que me suelen pasar a migrar a c#, despues de que sucesivos developers python que no fueron el orginal huyan de ese projecto es una mierda. En un lenguaje fuertemente typado es mas dificil hacer mierdas.
Por cierto, amigos de webedia, les falta la noticia de "las ips están a punto de acabarse!!!1111oneone"
#26 Es sensacionalista como una casa y un clickbait de libro. Pero claro, la sacan cada 2x3 porque saben que alguien va a picar y porque no falta quien menee estas cosas. Van a tiro hecho.
Veamos la pasta y hablamos.
Gente que conocía el negocio a fondo, a tomar por culo y le damos la informática a una
cárnica de mierdaconsultora externa, que ya sabemos como trabajan.Pues ahora no cuentan con gente que conozca a fondo del negocio ni el COBOL.
QUE SE JO DAN.
Y si no los hay, tranquilo que surgirán como generación espontánea. Es un problema de salario.
Verás, la mayoría de veces programar tiene más de entender el negocio que estás programando y los fundamentos de su CORE que de saber poner ifs, loops o return. Al fin y al cabo, un lenguaje de programación, es un idioma, que se puede comparar a ladrillos... y en cambio, con ese mismo ladrillo, lo mismo construyes una mansión, una catedral, una casa en el bosque o un rascacielos.
Pues aquí lo mismo... esto va de "arquitectura", y la arquitectura de aplicaciones implementadas en COBOL aparte de prehistóricas y nula documentación... en un mundo financiero que permite pràcticamente ningún error... es terrible, letal, poner a alguien que no comprende las repercusiones de poner o no un 0 o un null en un campo... puede cambiar absolutamente todo y tardar meses en poder depurar dónde està el error.
Vamos, es un problema de prehistoria funcionando en el siglo XXI, nadie se atreve a apagar dichos servidores, porque no hay equivalente que los reemplace, y a su vez, necesitan adaptar los cambios que imponen las legislaciones y leyes... en fin, un caos.
Son programas que llevan tiempo sin recibir actualizaciones, al menos en sus capas más interiores. Llevan decadas contratando desarrolladores para llevar algunas funcionalidades a otros entornos. Pero eso es la periferia del programa. El núcleo no se toca y si en algún momento alguien decide una partida presupuestaria para hacer cambios será un sprint enormey largo para migrar a C++, Java o alguna cosa más moderna lo que hay e independizarlo del mainframe y su ecosistema: CICS, MQSeries, DB2,ME series. En algún momento parecía que esas tecnologías emergerían en UNIX. De hecho están soportadas en AIX, pero sigue siendo ser cauitivo de IBM, de su hierro y de su sistema operativo.
Yo no puedo hablar por los demás, pero no tengo ganas de ponerme a destinar como funciona un sistema arcano para re implementarlo en una arquitectura moderna, porque no es nada estimulante.
Un banco no entiende por qué tiene que pagar otro desarrolló para tardar años en tener que ya hace lo mismo que hace el programa que tiene y que está amortizado. El jefe de sistemas si lo entiende, pero los responsables de negocio no quieren pasar por ahí.
Conón profesional no tengo ganas de formarme para un proyecto que es un nicho diminuto y que parece que va a ser cancelado en cualquier momento. O no se o tenemos éxito y finaliza y tampoco nos necesitan.
Python aunque es de tipado dinámico también es de tipado fuerte. Y es, sin lugar a dudas, el lenguaje más minimalista y legible de todos.
Por lo general, Python hace en 5 líneas lo que otros hacen en 10. Y está enfocado para no dar rienda suelta a la imaginación en las implementaciones. En Python las cosas solo se hacen de una manera (o al menos esa es la idea zen). Además obliga a intentar correctamente. ¿Qué más quieres?
www.precisely.com/blog/mainframe/9-mainframe-statistics
planetmainframe.com/2022/12/relevance-of-mainframe/
El Mainframe todavía controla el mundo!
Antes que eso preferirían pagar a un buen desarrollador de <lenguaje moderno> que reescribiera la aplicación desde cero.
Cualquiera de las dos opciones es mucho dinero que prefieren quedarse para bonuses de esos.
Un código que es a vez c# y python no sé ni como llamarlo.
Desarrollo en un ERP de RRHH para empresas grandes (>5000 empleados). Nada he visto más rápido para gestionar un proceso batch grande y complejo como un cálculo de nómina. Llevo unos 7000 empleados en esa aplicación, y una nómina completa tarda unos 10 minutos (contando que más de la mitad del tiempo se lo come la base de datos con inserts y deletes)
La empresa editora nos ha dicho que quieren ir quitando COBOL como el core de la aplicación (porque nadie quiere desarrollar en ese lenguaje) pero ya asumen que de lo último (2030) que van a plantearse quitarlo es el batch de la nómina porque no encuentran nada tan rápido y eficiente
En definitiva, llevo 15 años oyendo que COBOL está muerto, y lo cierto es que antes acariciaré yo el trigo
Simple cuestión de pasta
El antiàcido es caro
Por cierto que algo esté fuera de control o no no es responsabilidad de la tecnología
No necesitas Kubernetes para una aplicación monolítica de intranet con 1000 usuarios diarios (ni 10000, ni 100000...) Tampoco necesitas una arquitectura de microservicios.