Portada
mis comunidades
otras secciones
#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".
Esa es la realidad.
#14 lo relata estupendamente.
Pay them more.
#FreeAssange
Esa es la realidad.
#14 lo relata estupendamente.
Pay them more.
#FreeAssange
#1:
Que paguen bien y verán como cualquier desarrollador con experiencia se apunta y se pone al día con la sintaxis de Cobol en muy poco tiempo.
#17:
#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.
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.
#21:
#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.
Yo en su dia sabia bastante ... dios me guarde de volver a usar nada de eso antes de retirarme.
#14:
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.
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.
#34:
#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.
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.
#18:
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.
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.
#52:
#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.
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.
#10:
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.
#4:
¿Os acordáis cuando dijeron que iban a sustituir a trabajadores por IAs si no volvían al trabajo en la oficina?
#3:
Entre la DATA DiVISION y la CONFIGURATION SECTION ... pues algunos PIC 999
Comentarios
Que paguen bien y verán como cualquier desarrollador con experiencia se apunta y se pone al día con la sintaxis de Cobol en muy poco tiempo.
#1 1+1 no es dos en este caso. El problema es que son programas que apenas han necesitado mejoras, estáticos y ahora ya no hay quien los modernice
#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.
#24 pero encendidas?? Eléctricas o a gasolina?
#28 si estan encendidas y tienen dientes en la cadena …
#7 una mierda. Pon pasta sobre la mesa y ya verás la de cracks que aparecen. Pero de los buenos buenos.
#7 si funciona, no se toca
#7 Es que habría que migrarlos, no "modernizarlos".
Simple cuestión de pasta
#89 la ley de la jungla IT. Hay tantos “se debía” o “habría que haber hecho” …
#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.
#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.
#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.
#21 #62 El viejo entorno mainframe... estaba chulo, tenía sus cosas con ese toque retro.
Espero no volver a tocarlo ni aunque la humanidad esté al borde de la extinción y su única posibilidad de supervivencia sea utilizar COBOL.
Pero estaba chulo, con sus JCL y sus rutinas de miles de líneas muchas de ellas copypaste de otras a la que habían cambiado una línea o un parámetro.
#62 Hercules MVS, gratuito, compiladores de Cobol y RPG, si quieres al más moderno, IBM tiene un emulador de z/OS la licencia se vende, creo que hay una edición de estudiantes, y si no, patapalo. Yo tengo instalado los dos emuladores.
#21 Tecnología dinosauria esperando que caiga un meteorito.
#21 que casi no se usan?. Echa un ojo:
https://www.precisely.com/blog/mainframe/9-mainframe-statistics
https://planetmainframe.com/2022/12/relevance-of-mainframe/
El Mainframe todavía controla el mundo!
#21 Como que casi no se usan¿ Si el 90% de las grandes corporaciones tienen instalaciones mainframes? Cuando ves tu bonito cajero con Windows o Linux y una pantalla de botones y colores, detrás, posiblemente este un z16 manejando las transacciones realizadas, y tiene un razón de ser, estabilidad.
#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.
#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.
#55 un programador con experiencia, eso que dices lo tiene superado en 10 días. Y en ese tiempo incluyo aprender la sintaxis.
#66 Lo de usar un lenguaje de los 50 no lo superas nunca.
#34 "Alguien que lleva años en el mundillo del desarrollo se aprende la sintaxis en una tarde"
Para aprender mainframe tus dos o tres semanas le echarás, pero bueno, se aprende relativamente rápido.
"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"
Meeec, COBOL no es así. La tendencia es a dar "becas" de un mes o mes y medio a gente que muchos de ellos ni son informáticos ni nada, te encuentras hasta algún periodista, y cuando acaban van directos a la cárnica a trabajar para Accenture, Everis o Indra, con subcontrata de por medio (o sea, dos niveles de "intermediarios" por delante del cliente) y cobrando el sueldo mínimo.
Por eso mismo dicen que no encuentran, porque los informáticos normales o no van a eso o si van trabajan un tiempo y cuando pueden se van rápido de ahí, van ahí como el que curra en el McDonalds un verano.
A los "viejos" de COBOL que sí ganaban su buen dinero los fueron jubilando mientras contrataban a becarios para ir ahorrando costes.
#11 Pues eso, que paguen más, y habrá más gente para aprender y ganar experiencia. Es lo que pasa cuando se planifica para ayer.
#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.
#17 Yo trabajé dos años con el como mucho, es insufrible pero si hay pasta lo retomo también.
#17 #20 Los de cuarenta tambien hemos trabajado en COBOL ... pero yo paso, soy generoso y dejo esta ocasion toda para vosotros ...
#25 Yo tengo 45 tampoco me pongas más años que estos ya pesan
#25 Algunos. Yo tengo cuarenta y me he librado. Creo que vivo mas feliz gracias a ello
#32 Pero eso es porque seguro que eres un perroflauta que ni siquiera hicistes la mili ... COBOL te hace un hombre
#40 Ah, si solo hubiese aprendido COBOL hoy tendria pelo en el pecho
#1 #17 #20 #25 400€/hora
Esa es la oferta en Freelance.com
#25 Yo con 39 no he visto COBOL nunca, en la Universidad ya dábamos Java y C++. Y con Java me he quedado desde entonces.
#17 pues he leído que pagan una pasta gansa
#29 En mi época era al contrario... si querías cobrar pasta debías salir del Cobol.
#17 tu lo has dicho. Cada vez que leo estás noticias para mí como leer el No se encuentran camareros.
#17 Lo mismo digo, hace siglos programé en Cobol/400.
Veamos la pasta y hablamos.
#17 Se me pone ácido el estómago solo de pensarlo....
El antiàcido es caro
#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".
Esa es la realidad.
#14 lo relata estupendamente.
Pay them more.
#FreeAssange
#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.
#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.
#63 Las has usado?
Por cierto que algo esté fuera de control o no no es responsabilidad de la tecnología
#93 Ya le digo que soy viejuno y sí, he usado algo de Kubernetes y Terraform. Soy de la vieja guardia y la filosofía de Terraform por ejemplo no me gusta, puede que sean manías mías, pero me he topado a veces con una sintaxis farragosa e ilógica que parecía parida con prisas en lugar de mantener una estructura intuitiva.
En otro orden de cosas, tampoco me gusta DevOps. Me parece un engendro mezclar desarrollo e infraestructura. Para proyectos pequeños está muy bien, pero en organizaciones grandes es un caos.
#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.
#100 microservicios, la nueva moda. Aún recuerdo cuando no eras nadie sino sabías Java Beans. He visto tantas tecnologías morir...
#52 #63 Estoy yo ahora hasta la cintura de mierda de K8S, Terraform... y no paro de pensar ¿qué vendrá después? ¿Viviré para verlo? al ritmo que va la informática supongo que si, espero no me toque la migración a la siguente moda.
#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 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.
#52 Si pagas más ya te digo que más de un cobolero (por no decir todos) deja esas moderneces para volver al redil.
Y si no los hay, tranquilo que surgirán como generación espontánea. Es un problema de salario.
#19 Asi es
#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.
#78 Hay muchos nichos enanísimos: profesionales que hablen dos lenguas dispares y minoritarias, expertos en un grupo muy específico de fertilizantes orgánicos, investigadores médicos con experiencia en el estudio de alguna enfermedad rara, etc, etc, etc. Los nichos enanos no suelen ser el problema, porque siempre hay algún friki que le gusta esas frikadas. Desde instalar SO antiguos de ordenadores en smartphones hasta hacer una lavadora a pedales. Hay gente para todo.
Al final todo se basa en lo mismo: quiero que hagas un trabajo altamente cualificado, pero no tan excitante a cambio de un salario de mierda, o unas condiciones de mierda o ambas cosas.
Si te pagaran un sueldazo tremendo. Ahora tu trabajo no se valora, se valora y se paga bien al CEO que se rasca los webos o la seta a dos manos.
#FreeAssange
#19 Ni siquiera necesitan pagar especialmente bien. Simplemente hacer una inversión y montar un equipo del tamaño que sea necesario y vaya migrando lo que hay, poniendo ese sistema en producción y haciendo espejo de todo lo que le pase al sistema principal. Hay varios casos de éxito por ahí de proyectos de este tipo.
El COBOL no es un lenguaje arcano. Es un coñazo, tiene sus trucos y demás. Pero no es el problema que te vas a encontrar cuando migres todo. De hecho estoy razonablemente seguro de que ChatGPT4 te puede generar código equivalente en Java de forma bastante acertada.
El problema es ese "bastante". Habrá ciertos corner cases en los que nadie habrá pensado y los requerimientos para el sistema llevarán décadas perdidos, por lo que tendrán que descubrirlos en el propio código "(¿Por qué a las cuentas bancarias que terminan en 4 se les aplican los intereses el día 2 en vez del 1?)". Eso requerirá de un equipo de desarrollo interno que conozca el negocio y que vayan documentando las cosas. Todavía hay una cantidad sorprendente de empresas que externalizan el 95% de su área de IT porque ellos "no se dedican a la informática" sin darse cuenta de que esa parte de IT es su negocio.
#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.....
#36
Y lo de progamar todo sin estructuras de datos.
https://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.
#58 Python es el nuevo Basic. Lento y sin estructura, fácil de aprender, horrible de mantener.
#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?
#80 Python es una calculadora programable muy potente (véase todo el uso en ML y demás) o un lenguaje de scripting moderno (es decir, alternativa a Bash scripting).
Usarlo para cualquier otra cosa es un tiro en el pie.
#80 Estoy de acuerdo con usted, es sólo que no me gusta esa forma de programar. No pretendo tener razón, pero cuando yo aprendí a programar algo (no mucho) lo que se usaba era C cuando uno quería "programar de verdad". Y es cierto que C es un infierno porque uno tiene que encargarse de casi todo, pero luego es tan rápido y eficiente que para mí compensa. En términos de coches Python es un cómodo Hyundai SUV automático, y C es un Ferrari GTO con la suspensión dura.
#80 perdona, pero Python no tiene tipado fuerte, tiene duck typing.
Lo que existe es type hints, que son opcionales, y que puedes violar sin problema.
#58 Es que Python es "tan fàcil...".
#58 al menos usan array y parametros uno a uno
#36 yo he visto returns en mitad de una función. Y por debajo un centenar de líneas de código que no sabes si las dejaron por si acaso, o por pereza
#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.
#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.
#77 Arquitectura prehistórica y nula, ole tus cordones, mira este video y me comentas que tiene de prehistórico y nulo el z/16 de IBM y luego vienes y me lo vuelves a contar.
#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 que reescribiera la aplicación desde cero.
Cualquiera de las dos opciones es mucho dinero que prefieren quedarse para bonuses de esos.
#1 Exacto. Yo lo tengo oxidado, pero no me llevaría más de un mes ponerme al día
#1 Correcto, yo lo abandone hace ya 4 años y salvo una subida acojonante de pasta no vuelvo a ese infernal entorno de desarrollo + el infernal trabajo para bancos.
#1 No solo eso. He conocido un konton de empresas que han ofrecido proyectos de migracion de servicios existentes a otros lenguajes. Son baratos? No. Es mas barato seguir manteniendo la mierda que hay? Si. Es un problema de dinero no es un problema de los "programadores".
#1 Venga, va el chiste sobre cóbol:
Fue introducido en su cámara criogénica, los técnicos ajustaron la fecha en la que despertaría, le administraron inyecciones para ralentizar su pulso al mínimo, y ya está. Lo siguiente que vio Jack fue una enorme y moderna habitación llena de gente excitadísima. Todos gritaban "¡No me lo puedo creer!", "¡Es un milagro!", "¡Está vivo!". Había cámaras (que no se parecían a ninguna que hubiese visto antes) y equipamiento que parecía sacado de una película de ciencia ficción.
Alguien que obviamente era un portavoz del grupo se adelantó. Jack no podía contener su entusiasmo. "¿Ya está?" preguntó. "¿Ya ha llegado el 2000? ¿Se han terminado todas las fiestas de cambio de milenio y todas las crisis?". El portavoz le explicó que había habido un problema con la programación del temporizador de la cámara criogénica de Jack y no había sido preparada para el año 2000. En realidad, habían pasado 8000 años, pero el portavoz le dijo a Jack que no debía enfadarse. Alguien MUY importante quería hablar con él en ese mismo momento. De repente, una pantalla del tamaño de una pared mostró la imagen de un hombre que se parecía mucho a Bill Gates. Era el Primer Ministro de la Tierra. Le dijo a Jack que no se enfadara, que ésta era una época magnífica para vivir. Había paz mundial y no había hambre; el programa espacial había continuado y ya existían colonias en la Luna y en Marte; la tecnología había avanzado hasta tal punto que todo el mundo tenía interfaces de realidad virtual que les permitían ponerse en contacto con cualquier otra persona en el planeta, o ver cualquier espectáculo, o escuchar música grabada en cualquier lugar. "Eso suena maravilloso," dijo Jack, "pero ¿por qué está todo el mundo tan interesado en mí?" "Bueno", dijo el Primer Ministro, "el año 10000 está a la vuelta de la esquina, y en tu currículum dice que sabes COBOL ...".
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.
#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í.
#14 Bruto o neto? Cuidado eh?
seaCOBOL mundo
#5 me estás robando el upvote a punto de pistola
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.
#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...
#38 un banco no es nada especial. Claro que hay cosas mejores que cobol, otra cosa es que a la vez que cobol tengas que cambiar 7 cosas más.
El lenguaje rara vez es el problema.
#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...
#43 he trabajado en un banco español y ahora en una faang. Créeme, un banco no es nada especial.
#c-39" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3887127/order/39">#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.
#c-61" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3887127/order/61">#61 el lenguaje no es el problema siempre que lo conozcas.
Un código que es a vez c# y python no sé ni como llamarlo.
#85 pyc#hón
#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.
#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.
#38 Yo llegue a trabajar con los 4381 mira si soy viejuno, ahora z/16 en z/OS
#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.
#45 En efecto. Y con ampliación y reducción de recursos en caliente cuando no había virtualización siquiera.
#45 er... que un IBM 3090, he dicho.
#18 Doy fe
¿Os acordáis cuando dijeron que iban a sustituir a trabajadores por IAs si no volvían al trabajo en la oficina?
#4 Yo recuerdo el meneo este que salió por aquí, lo que no dice lo de volver a la oficina: IBM pausará contrataciones en un plan para sustituir 7.800 puestos de trabajo por IA
IBM pausará contrataciones en un plan para sustitu...
es.investing.comEl 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.
#10 la IA reservando unos céntimos en cada transacción para construir skynet
#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.
#10 Recuerdo en un extinto banco Andorrano con relaciones por Madrid... que existía un programa básico que ya no tenían el código fuente.
Entre la DATA DiVISION y la CONFIGURATION SECTION ... pues algunos PIC 999
#3 Oye, llama a IBM a ver...
#3 Ya tiré yo algunos procedures division y perform en mi vida.........durante el siglo pasado
#9 Vendo Ciro de la Fuente.
#12 Pues no...
https://www.casadellibro.com/libro-curso-de-programacion-rm-cobol-85/9788478970704/37743
185€ ahora de segunda mano!! Con que alegría lo tiré a la basura!! jajaja
#3 ¡Ay, COBOL! ¡Qué recuerdos! Después de 200 líneas de código aún no has empezado el algoritmo para hacer un programa básico.
#47 Esas se copiaban de otro siempre, los había que ni cambiaban el AUTHOR,
#47 no como ahora, que cualquier Framework te hace una carpeta de proyecto que ocupa 100 megas para poner Hola Mundo en una pantalla
#83 Sacto. Ahora "hace falta" un framework hasta para eso
#47 Eso se automatiza en C
Yo mismo dejé el cobol por .Net por la poca proyección (poca oferta y mal pagada)
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.
#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.
Yo he trabajado desarrollando en Cobol. Ya en su día la media de edad de mis compañeros era muy alta y hace diez años.
Si funciona, no lo toques.
#42: Eso es lo que debería resumir la noticia.
"...es que así es más moderno y blablabla" ---> Palabrería de Power Point, no hacer caso.
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.
#2 está siendo habitual eso en las consultoras. En Septiembre mismo vi alguna, no sé los requisitos, probablemente dominar algún otro lenguaje.
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.
Cansinos. No podía cerrar el año sin que algún medio xataquero dijera una vez más lo de que no hay programadores de Cobol
Por cierto, amigos de webedia, les falta la noticia de "las ips están a punto de acabarse!!!1111oneone"
O la noticia no lo explica o es una exageración.
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.
#26 ¿Un banco? Joder el día que haya que cambiar la primera capa, se va a la mierda el sistema bancario.
#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í.
#26 COBOL no supone "una manera de pensar diferente".
Que le pregunten al ChatGPT...
Que pesados, me vas a decir que IBM no tiene una IA tipo Watson para programar o sacarse las dudas?