Portada
mis comunidades
otras secciones
#1:
Cobol. Cuando empecé la carrera por el 92 estaba mueriendo....juas!
#15:
Me parece muy lógico, si un lenguaje de programación cubre tus necesidades y funciona de forma fiable... ¿Para que reescribir el código arriesgándote a meter nuevos errores?
#12: ¿Se puede seguir trabajando con una plataforma AS/400 con un código COBOL escrito hace 30 años y remodelado a lo largo de los años?
La prueba de que se puede seguir trabajando la tienes en el día a día.
#12: ¿Se puede seguir trabajando con una plataforma AS/400 con un código COBOL escrito hace 30 años y remodelado a lo largo de los años?
La prueba de que se puede seguir trabajando la tienes en el día a día.
#37:
Aunque el mensaje es correcto, la realidad es otra.
El Java, C, C++ o lo que sea claro que puede hacer lo que hace el COBOL, el problema es que no hay huevos a tocar unos programas que llevan 20 años funcionando y tienen una red de interdependencias que no conoce ni el tato. El apagar un programita en COBOL puede arrastrar consecuencias en sistemas que ni se sospecha porque ni están documentados. Si a esto le añadimos que suelen mover el core del negocio y está relacionado con pasta, el COBOL va a durar tanto como el banco.
Esto es extrapolable a los sistemas (en el lenguaje que sea) que lleven 15 años o más. También han desarrollado una red de dependencias que nadie se atreve a desentramar.
Si no se quita el COBOL no es porque no se pueda, es que no hay huevos (que conste que yo tampoco me atrevería)
El Java, C, C++ o lo que sea claro que puede hacer lo que hace el COBOL, el problema es que no hay huevos a tocar unos programas que llevan 20 años funcionando y tienen una red de interdependencias que no conoce ni el tato. El apagar un programita en COBOL puede arrastrar consecuencias en sistemas que ni se sospecha porque ni están documentados. Si a esto le añadimos que suelen mover el core del negocio y está relacionado con pasta, el COBOL va a durar tanto como el banco.
Esto es extrapolable a los sistemas (en el lenguaje que sea) que lleven 15 años o más. También han desarrollado una red de dependencias que nadie se atreve a desentramar.
Si no se quita el COBOL no es porque no se pueda, es que no hay huevos (que conste que yo tampoco me atrevería)
#7:
Pues va a ser que no estoy de acuerdo. ABAP es una alternativa muy "elegante" a COBOL.
Lo que pasa es lo que pasa siempre: A ver quién es el chulito que migra el HOST ese que lleva 22 años encendido.
Lo que pasa es lo que pasa siempre: A ver quién es el chulito que migra el HOST ese que lleva 22 años encendido.
editado:
Todo lo demás, son excusas.
#6:
Corred Obsoletos, Buscaos Otro Lenguaje
#22:
#16 Curiosamente los programas más antiguos son los más óptimos ya que la potencia de las máquinas de la época era la que era. El ZX-81 tenía un ajedrez que ocupaba la escandalosa cifra de 1kb. Recuerdo también una entrevista al equipo de Dinamic cuando sacaron el Aspar GP donde hablaban de haber tenido que eliminar una decoración de un circuito porque pesaba demasiado, cosas casi-impensables hoy en día.
Un buen paralelismo creo que sería con los editores de texto. A día de hoy cualquier editor de texto te permite hacer 800 cosas, desde formatear y maquetar texto hasta diseñar diagramas pero si tus necesidades únicamente son de formateo de texto seguramente cualquier editor de texto de los 80 cubra todas tus necesidades con un consumo ínfimo de recursos. Con los programas de gestión pasa lo mismo: si tus necesidades son las mismas que hace 20 años (y en la mayoría de casos, al igual que con los editores de texto, lo son) hay muy pocas soluciones modernas que sean más óptimas que las antiguas.
Como anécodta personal recuerdo la primera empresa para la que trabaje que estaba migrando todos sus programas de Prolog a un lenguaje moderno (velazquez, actual velneo) y no había ni un solo cliente que no se quejase de que los programas nuevos en sus superservidores modernos iban más lentos que sus viejos y vetustos servidores con su software en Prolog. Por supuesto todos decían que era mucho más bonito el tener barras de progreso, interfaces gráficas, botoncitos... pero a la hora de la verdad todos trabajaban más lento que, a fin de cuentas, es lo que les importaba.
#17 ¿Un experto en Cobol? Sin levantarme de mi silla tengo a 2 enfrente. Si me levanto y me doy una vuelta por el departamento creo que son unos 20 (y eso solo en una empresa que, además, solo tiene una parte de sus sistemas en Cobol). Depende mucho del sector en el que trabajes pero expertos en Cobol hay muchos más de los que pueda parecer.
Un buen paralelismo creo que sería con los editores de texto. A día de hoy cualquier editor de texto te permite hacer 800 cosas, desde formatear y maquetar texto hasta diseñar diagramas pero si tus necesidades únicamente son de formateo de texto seguramente cualquier editor de texto de los 80 cubra todas tus necesidades con un consumo ínfimo de recursos. Con los programas de gestión pasa lo mismo: si tus necesidades son las mismas que hace 20 años (y en la mayoría de casos, al igual que con los editores de texto, lo son) hay muy pocas soluciones modernas que sean más óptimas que las antiguas.
Como anécodta personal recuerdo la primera empresa para la que trabaje que estaba migrando todos sus programas de Prolog a un lenguaje moderno (velazquez, actual velneo) y no había ni un solo cliente que no se quejase de que los programas nuevos en sus superservidores modernos iban más lentos que sus viejos y vetustos servidores con su software en Prolog. Por supuesto todos decían que era mucho más bonito el tener barras de progreso, interfaces gráficas, botoncitos... pero a la hora de la verdad todos trabajaban más lento que, a fin de cuentas, es lo que les importaba.
#17 ¿Un experto en Cobol? Sin levantarme de mi silla tengo a 2 enfrente. Si me levanto y me doy una vuelta por el departamento creo que son unos 20 (y eso solo en una empresa que, además, solo tiene una parte de sus sistemas en Cobol). Depende mucho del sector en el que trabajes pero expertos en Cobol hay muchos más de los que pueda parecer.
#18:
#16 ¿Estas diciendo que un lenguaje de hace 22 años consume mas recursos que un lenguaje actual? Te puedo asegurar que el mismo codigo que se programa hoy en dia podria correr tranquilamente en una maquina de hace 5,10 ó 15 años de antiguedad.
Aparte que el lenguaje esta mas que trillado y los posibles debug estan mas que conocidos y catalogados. Puesto que no ha cambiado apenas el codigo , no hay errores nuevos por conocer.
Ademas te puedo presentar a mas 15 programadores entre ellos varios expertos. Aun se enseña el lenguaje, y en estos momentos hay empresas que realizan cursillos para enseñar a sus nuevas incorporaciones.
Aparte que el lenguaje esta mas que trillado y los posibles debug estan mas que conocidos y catalogados. Puesto que no ha cambiado apenas el codigo , no hay errores nuevos por conocer.
Ademas te puedo presentar a mas 15 programadores entre ellos varios expertos. Aun se enseña el lenguaje, y en estos momentos hay empresas que realizan cursillos para enseñar a sus nuevas incorporaciones.
#167:
#163 Se da la casualidad de que yo sí he trabajado con mainframes.
La gente mitifica tanto los entornos bancarios que casi da miedo decir que COBOL es una mierda pinchada en un palo y que su valor no está en su capacidad para manejar grandes volúmenes de datos, una frase que indica que ni se han molestado en ver los números que proporciona la mismísima IBM. COBOL no es zOS, no es DB2, no es CICS, y si le quitas todo eso se queda en nada.
El valor de COBOL es psicológico y práctico. Psicológico porque los dinosaurios que comenzaron con estos sistemas todavía están ahí, quizá en puestos de gran responsabilidad, y prefieren el malo conocido. Práctico porque COBOL es un lenguaje, y esto es históricamente preciso, inventado para que los contables hiciesen rutinas cuando no existían programadores a los que contratar.
Por eso cuando uno se pone a bucear entre los repositorios de código de un banco se encuentra atrocidades que harían llorar al peor informático de todos los tiempos. Y por eso también tu jefe puede ser biólogo y no tener ni puta idea de ingeniería del software.
COBOL estaba hecho para quienes no sabían programar, es el BASIC de la gente mayor y un cáncer para la informática.
Cualquier lenguaje con todas las herramientas y optimizaciones que IBM ha ido metiendo en sus mainframes para COBOL sería igual o mejor. De hecho en los manuales uno se encuentra que lo habitual es que soporten Java, ASM, C y COBOL (PL/1 si les vendieron la moto en los 80), y el único motivo, aparte del cuasi infinito catálogo de código en funcionamiento, por el que COBOL sigue ahí es que cualquier memo se puede poner a escribir rutinas que hagan altas, bajas, consultas y modificaciones en un par de semanas.
Es así de triste, y parece que tú no lo sabías.
La gente mitifica tanto los entornos bancarios que casi da miedo decir que COBOL es una mierda pinchada en un palo y que su valor no está en su capacidad para manejar grandes volúmenes de datos, una frase que indica que ni se han molestado en ver los números que proporciona la mismísima IBM. COBOL no es zOS, no es DB2, no es CICS, y si le quitas todo eso se queda en nada.
El valor de COBOL es psicológico y práctico. Psicológico porque los dinosaurios que comenzaron con estos sistemas todavía están ahí, quizá en puestos de gran responsabilidad, y prefieren el malo conocido. Práctico porque COBOL es un lenguaje, y esto es históricamente preciso, inventado para que los contables hiciesen rutinas cuando no existían programadores a los que contratar.
Por eso cuando uno se pone a bucear entre los repositorios de código de un banco se encuentra atrocidades que harían llorar al peor informático de todos los tiempos. Y por eso también tu jefe puede ser biólogo y no tener ni puta idea de ingeniería del software.
COBOL estaba hecho para quienes no sabían programar, es el BASIC de la gente mayor y un cáncer para la informática.
Cualquier lenguaje con todas las herramientas y optimizaciones que IBM ha ido metiendo en sus mainframes para COBOL sería igual o mejor. De hecho en los manuales uno se encuentra que lo habitual es que soporten Java, ASM, C y COBOL (PL/1 si les vendieron la moto en los 80), y el único motivo, aparte del cuasi infinito catálogo de código en funcionamiento, por el que COBOL sigue ahí es que cualquier memo se puede poner a escribir rutinas que hagan altas, bajas, consultas y modificaciones en un par de semanas.
Es así de triste, y parece que tú no lo sabías.
#97:
#7 Me pregunto qué leches tiene que ver ABAP con COBOL. Sí que ambos son lenguajes de programación... y punto.
COBOL es un lenguaje compilado con el que puedes desarrollar aplicaciones autónomas, y ABAP es un lenguaje que se usa exclusivamente dentro de una aplicación comercial (SAP) para extender sus funcionalidades.
COBOL es un lenguaje compilado con el que puedes desarrollar aplicaciones autónomas, y ABAP es un lenguaje que se usa exclusivamente dentro de una aplicación comercial (SAP) para extender sus funcionalidades.
#109:
#104 además de los bancos, muchas organizaciones grandes utilizan Cobol. La gracia, además de su sencillez, es que va asociado a sistemas IBM muy potentes, con DB2 y todo lo demás, que llevan 40 o 50 años mejorando. Y que se han establecido unos equipos de trabajo muy eficientes, con perfiles muy especializados en cada area, lo que mejora muchísimo la productividad. Y no hay que olvidar que su principal defecto (escasa evolución) es a la vez su principal ventaja, si lo que quieres es centrarte en desarrollar un producto/servicio y no tener que preocuparte constantemente por cambios tecnológicos.
#53:
Migrar el Cobol... Hoy debe ser el día de los inocentes informáticos.
Realmente nadie puede hacerlo con garantías y sobretodo nadie quiere asumir esas responsabilidades y riesgos. Los Mainframes de IBM sobre los que corre el Cobol tienen unos niveles de seguridad, eficiencia y funcionamiento a prueba de fallos absolutamente espectaculares, y no se equivoque nadie, son sistemas que se modernizan igual que todo lo demás, bueno, quizás algo más lentos, pero se modernizan, aunque los programas que llevan 40 años corriendo en ellos y que son el núcleo y corazón de auténticas corporaciones enormes no sean fácilmente modificables, ese "nivel" de integración con la lógica del negocio se ha perdido, cuando un programador actual de cobol y java pasan en 90% de su tiempo peleándose contra sus propias limitaciones y las de los lenguajes que utilizan (Java, sin ir más lejos, da trabajo en sí mismo, entre arreglos de fallos, softwares deficientes y demás, sin entrar siquiera en la lógica de negocio a grandes rasgos o ser capaz de presentar algo presentable en pantalla).
Me lo dijo una vez un jefe de informática de una empresa, El Cobol a nadie le gusta excesivamente, se ve antiguo y feo, pero funciona, joder que sí funciona, y el 90% de la lógica vital del negocio está en él. ¿Quién va a poner su trabajo en peligro por tener cuatro colorines más y acceso Web si no es 100% vital para la empresa? Sobretodo cuando el acceso Web lo puedes tener igualmente parcheando esos Coboles y buscando soluciones alternativas sin cambiar una línea del código "obsoleto", transformando el Java en un simple "frontend" del viejo y feo Cobol, que sigue siendo donde corre lo importante y que no puede fallar.
Os tocará la moral a los de Java, pero las cosas son como son.
Realmente nadie puede hacerlo con garantías y sobretodo nadie quiere asumir esas responsabilidades y riesgos. Los Mainframes de IBM sobre los que corre el Cobol tienen unos niveles de seguridad, eficiencia y funcionamiento a prueba de fallos absolutamente espectaculares, y no se equivoque nadie, son sistemas que se modernizan igual que todo lo demás, bueno, quizás algo más lentos, pero se modernizan, aunque los programas que llevan 40 años corriendo en ellos y que son el núcleo y corazón de auténticas corporaciones enormes no sean fácilmente modificables, ese "nivel" de integración con la lógica del negocio se ha perdido, cuando un programador actual de cobol y java pasan en 90% de su tiempo peleándose contra sus propias limitaciones y las de los lenguajes que utilizan (Java, sin ir más lejos, da trabajo en sí mismo, entre arreglos de fallos, softwares deficientes y demás, sin entrar siquiera en la lógica de negocio a grandes rasgos o ser capaz de presentar algo presentable en pantalla).
Me lo dijo una vez un jefe de informática de una empresa, El Cobol a nadie le gusta excesivamente, se ve antiguo y feo, pero funciona, joder que sí funciona, y el 90% de la lógica vital del negocio está en él. ¿Quién va a poner su trabajo en peligro por tener cuatro colorines más y acceso Web si no es 100% vital para la empresa? Sobretodo cuando el acceso Web lo puedes tener igualmente parcheando esos Coboles y buscando soluciones alternativas sin cambiar una línea del código "obsoleto", transformando el Java en un simple "frontend" del viejo y feo Cobol, que sigue siendo donde corre lo importante y que no puede fallar.
Os tocará la moral a los de Java, pero las cosas son como son.
#118:
#87 #54 Lo de que Java está diseñado para correr en electrodomésticos es más viejo que Matusalén: Java hace años que está diseñado para correr en mainframes y soportar cargas de trabajo bestiales. Precisamente cuando hablamos de mainframes lo que ocupa la MV es una nadería: ¿a quién le importa que cualquiera programa necesite de 30MB para arriba cuando todo lo que tiene que soportar ocupa 16GB en RAM? Yo estoy manteniendo un sistema que no para de evolucionar desde hace 20 años, decenas de miles de clases que no paramos de modificar y testear... y funciona. Y está muy relacionado con el mundo de los bancos en cuanto a que tenemos decenas de miles de usuarios y transacciones monetarias.
Y para nada esta noticia me afecta a la moral... bueno, sí, pero positivamente: si se quejan de que Java es mucho más compacto que COBOL y caben más errores en menos líneas, ahora me puedo reír de los que me hablan de Python o Ruby para cosas grandes, porque Java les parece demasiado "explícito" (verbosed)
Que los bancos tengan un departamente de software tan cutre que no sean capaces de hacer una migración como dios manda es una cosa, y otra que COBOL sea lo mejor hoy día para estos sistemas. COBOL sigue siendo un sistema válido... pero NADIE empieza hoy día un proyecto desde cero en COBOL.
Y para nada esta noticia me afecta a la moral... bueno, sí, pero positivamente: si se quejan de que Java es mucho más compacto que COBOL y caben más errores en menos líneas, ahora me puedo reír de los que me hablan de Python o Ruby para cosas grandes, porque Java les parece demasiado "explícito" (verbosed)
Que los bancos tengan un departamente de software tan cutre que no sean capaces de hacer una migración como dios manda es una cosa, y otra que COBOL sea lo mejor hoy día para estos sistemas. COBOL sigue siendo un sistema válido... pero NADIE empieza hoy día un proyecto desde cero en COBOL.
#3:
Ellos no necesitan una solución, necesitan no gastar dinero en migrar los sistemas. COBOL no tendrá problemas de seguridad supongo que porque tiene un propósito muy concreto y todos los sistemas de seguridad que hay por medio antes de llegar a aplicaciones desarrolladas en COBOL es enorme.
#65:
#37 Exacto. El problema de tocar COBOL y modernizarlo ( por asi decirlo ), es casi una quimera. Muchas partes del código estan sin documentar. Estuve trabajando un tiempo para el ayuntamiento, para modificar todos los programas COBOL a raíz del tema del efecto 2000 y habia partes de código que eran un cristo, nada o casi nada de documentación, preguntabas a alguien del departamento por si conocia esa parte del programa y nadie sabia nada. Cuando se lleva usando la misma estructura y se van añadiendo módulos sin control, al final pasan los años y ya nadie sabe para que se hicieron las cosas. Asi que la regla básica en informatica "si funciona no lo toques"
De todas formas, como comentáis, ni con un bomba nuclear se tumba algo en COBOL.
De todas formas, como comentáis, ni con un bomba nuclear se tumba algo en COBOL.
#87:
#53 Y porque nos iba a tocar la moral. Aquí hay cosas diseñadas para realizar X.
A lo que voy, cualquiera que entienda de Java ni se plantea sustituir COBOL con JAVA. Es absurdo comparar 2 lenguajes diseñados para cosas diferentes. Soy de los que piensan q ya va tocando sustituir COBOL porque por mucho que diga este tío tiene que haber soluciones mejores, pero como ya han dicho por ahí a ver quién es el guapo que cambia algo que esta hiperdepurado y que se conoce tan bien que todos los fallos que da son predecibles y controlables. A lo anterior añadiremos el insignificante detalle de que esas aplicaciones manejan la pasta.
De todas formas de sustituirse jamás debería hacerse por JAVA. simplemente porque Java no está hecho para ese tipo de operaciones intensivas. Java está hecho para llegar a cualquier equipo informático; se diseñó para que algo hecho con él pudiera ejecutarse hasta en una tostadora. Pero eso tiene un precio llamado JVM q es pesada hasta decir basta y es de locos usar algo tan pesado para hacer operaciones sobre datos de forma intensiva.
En resumen, la discusion COBOL Java me parece tan absurda como decir que es mejor un deportivo que un camión. Ambos son vehículos pero cualquiera puede ver que no se diseñaron para lo mismo por lo tanto no se puede comparar.
Asique que se planteen cambiar COBOL. Que se tomen su tiempo en probar nuevas soluciones pero las tiene q haber mejores y mejorables fuera de COBOL. Eso si x su bien que dejen java para los frontales web y no para las transacciones sino van a tener q aflojar una pasta en maquinas.
A lo que voy, cualquiera que entienda de Java ni se plantea sustituir COBOL con JAVA. Es absurdo comparar 2 lenguajes diseñados para cosas diferentes. Soy de los que piensan q ya va tocando sustituir COBOL porque por mucho que diga este tío tiene que haber soluciones mejores, pero como ya han dicho por ahí a ver quién es el guapo que cambia algo que esta hiperdepurado y que se conoce tan bien que todos los fallos que da son predecibles y controlables. A lo anterior añadiremos el insignificante detalle de que esas aplicaciones manejan la pasta.
De todas formas de sustituirse jamás debería hacerse por JAVA. simplemente porque Java no está hecho para ese tipo de operaciones intensivas. Java está hecho para llegar a cualquier equipo informático; se diseñó para que algo hecho con él pudiera ejecutarse hasta en una tostadora. Pero eso tiene un precio llamado JVM q es pesada hasta decir basta y es de locos usar algo tan pesado para hacer operaciones sobre datos de forma intensiva.
En resumen, la discusion COBOL Java me parece tan absurda como decir que es mejor un deportivo que un camión. Ambos son vehículos pero cualquiera puede ver que no se diseñaron para lo mismo por lo tanto no se puede comparar.
Asique que se planteen cambiar COBOL. Que se tomen su tiempo en probar nuevas soluciones pero las tiene q haber mejores y mejorables fuera de COBOL. Eso si x su bien que dejen java para los frontales web y no para las transacciones sino van a tener q aflojar una pasta en maquinas.
#103:
#84 Súper potente, súper grande, súper compleja, súper cara, con un motor súper obsoleto, y que como se te ocurra implantarlo te van a tener súper pillado por los huevos el resto de tu vida.
Claro que para grandes corporaciones no hay otra alternativa que usar SAP porque sencillamente no hay otra opción. Pero de todas maneras aquí se estaba hablando de bancos, que necesitan un animal totalmente distinto a un ERP.
Claro que para grandes corporaciones no hay otra alternativa que usar SAP porque sencillamente no hay otra opción. Pero de todas maneras aquí se estaba hablando de bancos, que necesitan un animal totalmente distinto a un ERP.
Comentarios
Cobol. Cuando empecé la carrera por el 92 estaba mueriendo....juas!
#0 El titular es una cagada. No dice nada específicamente de Java. Pone como ejemplo Java como lenguaje moderno que aporta problemas en vez de soluciones. Podría decir lo mismo de VB o cualquier otra cosa.
#1 Menos mal que no has visto cosas desarrolladas con FORTRAN 77. Que las hay.
#2 por desgracia si que las he visto, si...
#2 El titular es el original de la noticia
La verdad es que el artículo es un simple recordatorio del estado en el que se encuentran los sistemas informáticos del sector bancario.
Hay algo que no entiendo, ¿por qué no se olvidan de "migrar" el código existente y se dedicar a hacer un buen análisis de los procedimientos implicados para que así sea fácil realizar la programación en cualquier lenguaje? Me refiero, llevan décadas "migrando" el código y dedicando muchísimos recursos al asunto, no entiendo por qué siguen teniendo esta dependencia de COBOL/FORTRAN, la verdad.
#8 ¿Una pregunta tonta? ¿Necesita un AS/400 Java? Tratamos muchas veces de trasladar estos "avances" a plataformas que no los necesitan y nunca los van a necesitar.
Los entornos MF. No necesitan todas esas moderneces. Se busca estabilidad y rapidez.
#10 Hombre, es que se supone que un cambio de sistema implicará un cambio o adaptación de la plataforma, ¿no?
La cuestión entonces sería, ¿me permite la plataforma y sistema actual atender correctamente a todas mis necesidades actuales? ¿Puedo seguir actualizando mi sistema para acomodarlo a nuevos procedimientos o cambios en los procedimientos existentes?
¿Se puede seguir trabajando con una plataforma AS/400 con un código COBOL escrito hace 30 años y remodelado a lo largo de los años?
Me parece muy lógico, si un lenguaje de programación cubre tus necesidades y funciona de forma fiable... ¿Para que reescribir el código arriesgándote a meter nuevos errores?
#12: ¿Se puede seguir trabajando con una plataforma AS/400 con un código COBOL escrito hace 30 años y remodelado a lo largo de los años?
La prueba de que se puede seguir trabajando la tienes en el día a día.
#15 Me parece muy lógico, si un lenguaje de programación cubre tus necesidades y funciona de forma fiable... ¿Para que reescribir el código arriesgándote a meter nuevos errores?
Porque seguramente esté arrastrando código frankenstein que esté generando errores o consumo de recursos (CPU, RAM, tiempo de procesamiento) exagerados.
Porque seguramente cada mínima modificación que tengan que hacer sea carísima (y a lo mejor, de ahí viene que todos los procesos bancarios sean tan lentos y tediosos).
Porque el coste de mantenimiento tiene que andar por las nubes (¿dónde encuentras tú un experto en COBOL hoy en día?)
Hay muchos motivos. Otra cosa es que no quieran gastarse el dinero que cuesta rehacer el sistema porque prefieran pan para hoy.
#16: Porque seguramente esté arrastrando código frankenstein que esté generando errores o consumo de recursos (CPU, RAM, tiempo de procesamiento) exagerados.
¿Y si no lo hay?
Porque seguramente cada mínima modificación que tengan que hacer sea carísima (y a lo mejor, de ahí viene que todos los procesos bancarios sean tan lentos y tediosos).
Cualquier modificación va a ser cara, no por el código sino por poder asegurar que no afecte a la calidad del código.
Porque el coste de mantenimiento tiene que andar por las nubes (¿dónde encuentras tú un experto en COBOL hoy en día?)
Si tanto dinero se ganara con Cobol, la gente lo estudiaría en masa y el precio bajaría. Oferta y demanda.
#16 Curiosamente los programas más antiguos son los más óptimos ya que la potencia de las máquinas de la época era la que era. El ZX-81 tenía un ajedrez que ocupaba la escandalosa cifra de 1kb. Recuerdo también una entrevista al equipo de Dinamic cuando sacaron el Aspar GP donde hablaban de haber tenido que eliminar una decoración de un circuito porque pesaba demasiado, cosas casi-impensables hoy en día.
Un buen paralelismo creo que sería con los editores de texto. A día de hoy cualquier editor de texto te permite hacer 800 cosas, desde formatear y maquetar texto hasta diseñar diagramas pero si tus necesidades únicamente son de formateo de texto seguramente cualquier editor de texto de los 80 cubra todas tus necesidades con un consumo ínfimo de recursos. Con los programas de gestión pasa lo mismo: si tus necesidades son las mismas que hace 20 años (y en la mayoría de casos, al igual que con los editores de texto, lo son) hay muy pocas soluciones modernas que sean más óptimas que las antiguas.
Como anécodta personal recuerdo la primera empresa para la que trabaje que estaba migrando todos sus programas de Prolog a un lenguaje moderno (velazquez, actual velneo) y no había ni un solo cliente que no se quejase de que los programas nuevos en sus superservidores modernos iban más lentos que sus viejos y vetustos servidores con su software en Prolog. Por supuesto todos decían que era mucho más bonito el tener barras de progreso, interfaces gráficas, botoncitos... pero a la hora de la verdad todos trabajaban más lento que, a fin de cuentas, es lo que les importaba.
#17 ¿Un experto en Cobol? Sin levantarme de mi silla tengo a 2 enfrente. Si me levanto y me doy una vuelta por el departamento creo que son unos 20 (y eso solo en una empresa que, además, solo tiene una parte de sus sistemas en Cobol). Depende mucho del sector en el que trabajes pero expertos en Cobol hay muchos más de los que pueda parecer.
#22 Creo que esa sensación de que no queda nadie que sepa COBOL es porque no se ve, no se habla de él (es como el Club de la Lucha), parece que no se mueva nada... pero si no se ve movimiento es porque quien cruza la Puerta Oscura que guarda el espectro de Grace Hopper no sale hasta que se jubila.
#25 Jajaja lo has clavado.
#22 ¿Un experto en Cobol? Sin levantarme de mi silla tengo a 2 enfrente. Si me levanto y me doy una vuelta por el departamento creo que son unos 20
¿Navegando por meneame en horas de trabajo? Juan Manuel, pase por mi despacho mañana a primera hora
#49 Eso, y así echamos unas risas comentando los titulares.
#22 Más óptimas no pueden ser.
#20 #70 ¿Cómo se puede asegurar que un programa de esos -no trivial- no contiene errores? Yo aseguraría más bien lo contrario.
#22 Sobre la eficiencia: los algoritmos modernos son muchísimo más eficientes que los antiguos, a menudo se suele afirmar que el tiempo de ejecución de un algoritmo moderno en una máquina antigua es menor que el de un algoritmo antiguo en una máquina moderna.
Uno de los mayores problemas para migrar los sistemas en COBOL es, como se ha mencionado, la falta de documentación. Otro es el control de código, habría muchísima suerte si el código estuviese en un repositorio. Puede que todavía haya rutinas de COBOL guardadas en disketes de 5 1/4. Y ¿alguien se ha preguntado por los tests automáticos? ¿TDD? Si hubiesen desarrollado los fabulosos sistemas con técnicas basadas en tests automáticos, migrar a cualquier cosa sería más parecido a un paseo por una calzada de baldosas amarillas.
PD: ¿Cuánto fan de COBOL hay escondido por ahí?
#23 Si, creo que como bien dices, la antigüedad de los sistemas es el factor mas importante en este caso. El problema que le veo es que no es solo una parte la que tienes que migrar, sino que hablamos de gran parte de la infraestructura de tu negocio, y la gran mayoría son aplicaciones críticas, por los datos que manejan.
#17 Lo ganan los que están dentro y los pocos que se van incorporando. Es como un gremio, con un nicho de bastante seguridad como son los bancos y aseguradoras.
#17 Yo mismo me considero experto en COBOL, y hay muchísimos... en Madrid y Barcelona. ¿Lo que ganamos? Hombre, no somos mileuristas, pero tampoco es que nos vayamos a retirar a la edad de un futbolista...
Por cierto, el tío del informe no tiene ni pajolera idea de Cobol. ¿600 líneas un programa o rutina COBOL? En esas líneas entran poco más que comentarios, declaraciones de entorno, constantes, variables y unas pocas líneas de proceso. Un programa de 600 líneas es sencillísimo. Yo he trabajado con alguno de 30.000 líneas.
#70 600 líneas ya son líneas incluso para cobol, no hagamos código espagueti.
#81 Supongo que esto lo dices desde el desconocimiento y que no trabajas con Cobol... Acabo de abrir un programa al azar de los más simples que te puedes encontrar. Coge dos ficheros, cruza por sus claves y saca en otro fichero los registros que coinciden. Tiene 547 líneas. Y, créeme, no hace nada, no tiene ninguna lógica. Luego he abierto otro programa sencillito, que tiene algo de tratamiento de datos (no mucho) y tiene 994 líneas.
#81 como te dice #88 600 lineas en un programa Cobol es normal. Yo recuerdo que la media estaba en 1000 lineas por módulo.
#88 Tienes razón, no trabajo en Cobol.
#88 ¿547 líneas para hacer un join?
#70 30000 lineas de Código??? jur jur jur, no te has pasado un poco mucho?
La media 2000... bueno, si las COPY's las pones a saco, me creo lo de las 30000 ..pero de experto..
#96 No, no estoy exagerando. Obviamente es un caso extremísimo, se trataba del alta de un nuevo contrato de préstamos en una instalación en la que no había control de calidad de ningún tipo. Y no, las copys estaban "bien" puestas. Había una amalgama de párrafos, llamadas a rutinas, comentarios, modificaciones asteriscadas, código redundante, displays, etc, etc que era intratable. De hecho, cada vez que había que tocar algo, no compilaba por exceso de líneas, se volvía loco, literalmente. Teníamos que buscar displays y asteriscos inservibles para quitar y poder meter nuestras líneas. Pero vamos, te aseguro que la cifra es real. Obviamente, el programa no era mío, era fruto de una evolución descontrolada a lo largo de muchos años.
#70 #96 30000? Menudo chollo, en la aseguradora en la que trabajo el programa de contratación de pólizas tiene 112000 líneas.
#17 Yo soy AP Cobol, y mi sueldo es 30k
Vamos, lo habitual en Madrid, tampoco es para echar cohetes
#17
Al generar demanda de cobol estás provocando que la haya oferta de cobol ¿es eso bueno? ¿Es el cobol un lenguaje útil hoy día para otra cosa que no sean los bancos?
Es cómo si hablas de una emisora de radio que sólo usa discos de vinilo. Y dice, cambiarnos a digital ahora nos sale caro. Y tu dices, si la radio funciona lo que hay que hacer es más expertos en tocadiscos. Oferta y demanda.
Lo que pasa es lo de siempre, si se hubiese hecho progresivamente pues hoy no costaría tanto. Y defender el cobol, es cómo defender el IE6 para que siga funcionando en el ordenador del jefe.
#16 ¿Estas diciendo que un lenguaje de hace 22 años consume mas recursos que un lenguaje actual? Te puedo asegurar que el mismo codigo que se programa hoy en dia podria correr tranquilamente en una maquina de hace 5,10 ó 15 años de antiguedad.
Aparte que el lenguaje esta mas que trillado y los posibles debug estan mas que conocidos y catalogados. Puesto que no ha cambiado apenas el codigo , no hay errores nuevos por conocer.
Ademas te puedo presentar a mas 15 programadores entre ellos varios expertos. Aun se enseña el lenguaje, y en estos momentos hay empresas que realizan cursillos para enseñar a sus nuevas incorporaciones.
#16 Es software que ha estado en funcionamiento desde hace 20, 30, y hasta 40 y más años; tendría fallos, pero hace mucho que saltaron, se vieron y se arreglaron. Esos programas son el equivalente informático de los refugios antinucleares de la misma época, serán bastos, feos y pesados para los estándares de hoy, pero no los reventarías ni con una bomba atómica. Puede que despilfarren recursos - aunque lo dudo - pero errores no tienen.
Y respecto a las modificaciones y a donde encontrar expertos, no solo existen aún veteranos en activo, viejos guerreros de los 80 (y puede que hasta alguno de los 70) sino que quienes tienen software en COBOL se encargan de formar más para no quedarse sin gente. Te lo digo como alguien que aprendió a programar con COBOL hacia 1980 y que muy probablemente va a volver a trabajar en COBOL de nuevo este año después de haberlo dejado hace unos 25 años o más... vamos, aún usábamos GOTOs a mansalva
#16 El problema es que
seguramentecon toda seguridad no cubre las necesidades.Hoy en día, Los sistemas informáticos no son parte del banco, son el banco en sí mismo. Si la competencia tiene un sistema más moderno que le permite mejorar el procesado de datos, análisis de riesgo, control de morosos, sistemas IA, ... entonces el banco en cuestión está "jodido".
#15 Fijo que el programa no esta ni comentado, y que tienes que ir descifrando que hace cada linea o conjunto para luego traducirlo a un lenguaje mas moderno, que seguro que tiene algunas rutinas implementadas como funciones directamente en el lenguaje. Pero quien se arriesga a hacer eso, sabiendo que es un sistema critico y que se van a gastar una morterada en las pruebas de seguridad y estabilidad.
Mejor dejarlo como esta mientras funcione
#15 aquí el tema es que ese código no es ni fiable ni estable, la decisión a tomar es migro lo que tengo a una tecnología donde haya más facilidad de encontrar profesionales y sea más estructurado y de fácil comprensión o analizo lo que tengo lo descifro y documento debidamente para poder hacer un mantenimiento eficiente, pues la respuesta del autor es que es mejor la segunda opción, eficiencia y estabilidad? Ya estamos con lo de siempre, la pantalla verde es más rápida y eficiente por definición que cualquier framework de reciente factura y nada más lejos de la realidad tan malo puede ser un cobol poco optimizado como bueno un proceso Hibernate bien hecho, pero para eso hacen falta arquitectos no programadores haciendo procesos con un "how to" de javaHispano, con todo el cariño para javaHispano.
#37 #15 Desde luego Cobol no cubre las necesidades de un banco, ni de lejos, ¿Cuántas webs están hechas en cobol? Eso es sólo el comienzo, otra cosa es que Java sea la solución. Llevo años conviviendo con parte de la lógica hecha en cobol y es un auténtico infierno. Además de caro, carísimo en muchos aspectos.
Además de que a los agujeros de seguridad que se refiere este señor son comunes a cualquier servidor sea del lenguaje que sea incluido cobol. Es lo tiene la interoperatibilidad.
#12 no olvides la seguridad (muy económica) que ofrece el AS/400, ahora conocido como iSeries. Un C2.
http://en.wikipedia.org/wiki/Trusted_Computer_System_Evaluation_Criteria
#10 Yo soy de la opinión de que "si no está roto, no lo arregles."
#10 A mi juicio este no es artículo escrito por un especialista en la materia, se sueltan muchos conceptos ambiguos que en el mundo de la informática carecen de significado y contexto. Es cierto que una tecnología que nace ahora es mejor que otro que ya existía. Lamentablemente en informática se buscan soluciones/metodologías que sirvan para cualquier proyecto, y en el mundo real no funciona así.
“Los programas COBOL son inmensamente complejos, el tamaño de sus módulos tiene 600 líneas de código. Mientras que el tamaño de un módulo Java tiene 30 líneas de código”, ha declarado. "En COBOL existe una fuerte correlación entre el tamaño del sistema y de la densidad de los defectos. Es exponencial, cuanto mayor es el sistema, más alta es la densidad de los defectos en cada cien líneas ",
La modularización tiene sus puntos fuertes, pero no es una panacea, muchas veces al dividir un todo en módulos tienes muchos más problemas antes, incluso problemas que no tenías, y tampoco es seguro que unas partes con menos errores, conformen un todo con menos errores.
Incluso muchas veces se usan lenguajes orientados a objetos como si fueran programación estructurada (cosas como abusar de getters y setters), y no siempre el principio de ocultación de la información funciona bien. Hay muchas soluciones teóricas, que en principio suenan muy bien, pero en la práctica no son tales. Hay que saberlas evaluar.
Además, al tratarse de sistemas antiguos hay muy poca gente cuyos conocimientos técnicos permitan detectar y resolver rápidamente los problemas que surgen.
Esto depende de cuanto estés dispuesto a pagar y cuanta estabilidad estés dispuesto a ofrecer. En España esto es un mal genérico que aplica a cualquier tipo de modelo de desarrollo.
#8 Yo creo que por seguridad.
#2 ¿Me puedes decir qué tienes contra el fortran 77? Fuera de coñas, hay mucho soft científico y técnico circulando y en uso que está escrito en fortran. De hecho incluso en forma de extensiones para cosas tan actuales como python o similares. Si os fijáis, fortran es frontend de compiladores como los gnu o llvm.
#2 Fortran se usa en la mayoría de software para cálculos en física y química subatómica. Yo lo estudié en la carrera, hace 12 años.
#1 Lo mismo me dijeron del ASP, ahora me lo dicen del PHP, pero sigo haciendo en los dos soluciones buenas y fiables.
#1 Bill Gates dijo algo así como: No sé que leguajes de programación habrá en el futuro, pero COBOL seguirá existiendo"
#45 esto es simplemente una realidad, nada de propaganda ni conspiranoias.
#43 lo mismo que decía Bill Gates yo ya lo tenía claro hace 25 años. Mi primera profesora de Cobol siempre tenía esa frase en la boca.
#47 La cuestión no es si tiene razón, que es muy discutible, la cuestión es por qué ha tenido que salir a decir esto ese analista precisamente ahora... si fuese tan evidente no se habría molestado.
De hecho el texto refuerza mi afirmación (no es muy largo así que no voy a pegar nada): lo que pretenden es acallar las críticas internas y convencer a la opinión pública de que es la mejor o que no hay otra opción.
#43 ¿El mismo Bill Gates que dijo que nadie necesitaría más de 640K de RAM en el futuro?
#74 No, este no existe.
Corred Obsoletos, Buscaos Otro Lenguaje
Pues va a ser que no estoy de acuerdo. ABAP es una alternativa muy "elegante" a COBOL.
Lo que pasa es lo que pasa siempre: A ver quién es el chulito que migra el HOST ese que lleva 22 años encendido.
#7 apuesto a que llevas razón, no es de extrañar,... da pereza y reparo migrar algo en cuanto sea un poco crítico, no me quiero imaginar a esos niveles, tiene que ser el Coco y te inventas cualquier excusa como que el Java o el otro no es lo bastante seguro.
#40 Y que a ver quién averigua todo lo que hace esa hipotética caja que ya te digo, en la mayoría de los casos llevan de cinco años para arriba sin un reinicio, porque como "te dejes algo" ya "la has cagao" y tienes 20 integraciones que te fallan y es cuando se pierden transferencias, se quedan lelos los cajeros, etc...
Pero no os creáis, que se va haciendo, ¿eh?
#68 Por higiene se suelen reiniciar (IPL), al menos bianualmente coincidiendo con el cambio de hora por ejemplo (aunque no es necesario)
#78 entonces te refieres a semestralmente?
#7 He leído ABAP y elegante y no he seguido leyendo más comentarios...
Lo que les faltaba a los bancos, atarse a SAP.
#75 qué alternativa propones... PHP + MySQL? O igual quieres hacer todo el sistema en Java?? Es una locura, Java para la interfaz.
Ahora mismo SAP es, te guste o no, una plataforma super potente.
#84 ya empezamos. Tienes alguna idea de lo que se puede hacer en PHP y MySQL, o has leido cuatro cosas sobre software libre y te suena a perroflautas y rojos peligrosos?
Lo del SAP es de juzgado de guardia. Que metan esos clavos por implantarte un sistema rígido y cerrado, que implica enormes dificultades de adaptación, solo es posible porque quién toma la decisión de comprar SAP no tiene demasiada idea de informática y se ha dejado convencer (o untar) por algún comercial.
Podría hablarte de una famosa ONG que se dejó varios millones de euros en un SAP cuando se le propusieron otras soluciones en software libre por un 10% del coste.
#89 ni software libre ni nada de eso, hablo de potencia, de facilidades. De tener un sistema complejo montado en apenas dos semestres, que con otros lenguajes podría llevar una década. Mantenimiento, utilidades... todo el entorno de SAP si sabes cómo manejarlo...
En fin que yo tampoco digo que sea la panacea SAP, pero que no veo yo a un banco montando sus sistemas en PHP + MySQL... o en Java... Lol.
#94 no ves a un banco montando sus sistemas en php, mysql o java porque seguramente desconoces estos lenguajes. Yo he trabajado también con el lenguaje de programación de SAP (el ABAP) y es un lenguaje lamentable. Le faltan muchísimas cosas y utilidades que tiene cualquier lenguaje decente, que hacen que la tarea del programador sea más eficiente.
La potencia depende principalmente del hardware, así que el SAP no se justifica tampoco por ese lado.
#99 dime algunas de ellas... ABAP es un lenguaje orientado a objetos como los demás, con sus private, public, protected (sí, también tiene herencia!), variables estáticas... además de poder manejar fácilmente sentencias SQL. Dispone de excepciones, clases locales, globales...
Y luego además dispones de todo el entorno SAP.
Ah y si quieres, puedes usar el Dynpro o el Webdynpro para las interfaces.
Dime qué utilidades le faltan porque yo ahora mismo no caigo.
#94 Que el software sea libre o no es totalmente independiente de que sea potente o tenga "facilidades"
#94 está claro, Facebook está pensando migrar sus sistemas a COBOL o a SAP porque los comentaristas de esta noticia dicen que es lo más de lo más
#84 Súper potente, súper grande, súper compleja, súper cara, con un motor súper obsoleto, y que como se te ocurra implantarlo te van a tener súper pillado por los huevos el resto de tu vida.
Claro que para grandes corporaciones no hay otra alternativa que usar SAP porque sencillamente no hay otra opción. Pero de todas maneras aquí se estaba hablando de bancos, que necesitan un animal totalmente distinto a un ERP.
#7 Como decia un profesor mio de la carrera, si algo funciona no lo toques.
Al final es coste de migrar sistemas de este tipo se dispara, porque no es solo el software de la aplicación si no hardware, migración de datos, tests....
#7 Me pregunto qué leches tiene que ver ABAP con COBOL. Sí que ambos son lenguajes de programación... y punto.
COBOL es un lenguaje compilado con el que puedes desarrollar aplicaciones autónomas, y ABAP es un lenguaje que se usa exclusivamente dentro de una aplicación comercial (SAP) para extender sus funcionalidades.
#7 ABAP ni es elegante ni es una alternativa a nada. En ABAP no se pueden hacer ni la mitad de cosas que en Cobol, Java, PHP u otros. Al menos era así hace unos años.
#100 Hombre, con ABAP puede hacerse exactamente lo mismo que con Cobol, RPG, PHP, etc. Es un lenguaje cómodo y potente en tratamiento de datos, aunque está orientado al entorno del ERP del que forma parte. Y SAP es una gran herramienta.
Aunque el mensaje es correcto, la realidad es otra.
El Java, C, C++ o lo que sea claro que puede hacer lo que hace el COBOL, el problema es que no hay huevos a tocar unos programas que llevan 20 años funcionando y tienen una red de interdependencias que no conoce ni el tato. El apagar un programita en COBOL puede arrastrar consecuencias en sistemas que ni se sospecha porque ni están documentados. Si a esto le añadimos que suelen mover el core del negocio y está relacionado con pasta, el COBOL va a durar tanto como el banco.
Esto es extrapolable a los sistemas (en el lenguaje que sea) que lleven 15 años o más. También han desarrollado una red de dependencias que nadie se atreve a desentramar.
Si no se quita el COBOL no es porque no se pueda, es que no hay huevos (que conste que yo tampoco me atrevería)
#37 Exacto. El problema de tocar COBOL y modernizarlo ( por asi decirlo ), es casi una quimera. Muchas partes del código estan sin documentar. Estuve trabajando un tiempo para el ayuntamiento, para modificar todos los programas COBOL a raíz del tema del efecto 2000 y habia partes de código que eran un cristo, nada o casi nada de documentación, preguntabas a alguien del departamento por si conocia esa parte del programa y nadie sabia nada. Cuando se lleva usando la misma estructura y se van añadiendo módulos sin control, al final pasan los años y ya nadie sabe para que se hicieron las cosas. Asi que la regla básica en informatica "si funciona no lo toques"
De todas formas, como comentáis, ni con un bomba nuclear se tumba algo en COBOL.
#65
Aparte de eso, suele haber una experiencia muy desastrosa en el proceso de retirada de aplicaciones. Apagas una y se caen 10 que dependían de ella, directa o indirectamente.
Dónde trabajé durante años, toda la planta está almacenada en un sistema mainframe (tan moderno que ni siquiera incluye DNI para identificar al propietario, eso hay que ir a buscarlo a otro sistema) y el resto de los sistemas de la compañía han crecido a su alrededor.
El cambiar esto, significa al menos, volver a probarlo todo. En el peor de los casos, modificar cientos de aplicaciones que también han evolucionado y crecido de una manera similar.
Luego hay una segunda derivada, un poco más cachonda. En su día y con el efecto 2000 hubo que recuperar a algún dinosaurio de IBM para modificar programa en ensamblador del OS/360 (ni me acuerdo que CPU llevaba)
Había dos teorías para justificar aquellos programas en ensamblador:
- Eficiencia. Eran programas muy rápidos, adecuados a las soluciones HW de su época.
- Hemos perdido los fuentes y no han quedado más cojones que desemsamblar y modificar aquí.
Cada cual que elija la que más le guste.
#37 Si que hay huevos, todos los días nos papamos programas de hace 20 años para adaptarlos, corregirlos, etc...
Ya mas en serio, no solo se mantienen sistemas antiguos, también se crean aplicaciones nuevas todos los años, y se continúan haciendo en cobol.
Se adapta a las necesidades, es robusto, fiable y procesa grandes cantidades de información muy rápido.
por los dioses de COBOL!
#13 ¡Por las 13 colonias!
Ellos no necesitan una solución, necesitan no gastar dinero en migrar los sistemas. COBOL no tendrá problemas de seguridad supongo que porque tiene un propósito muy concreto y todos los sistemas de seguridad que hay por medio antes de llegar a aplicaciones desarrolladas en COBOL es enorme.
#3 Sale mas caro encapsular el cobol en java que en migrarlo todo. Otra cosa es quitar un sistema con un rodaje de mas de cincuenta años. Algo de razon tiene el articulo
Migrar el Cobol... Hoy debe ser el día de los inocentes informáticos.
Realmente nadie puede hacerlo con garantías y sobretodo nadie quiere asumir esas responsabilidades y riesgos. Los Mainframes de IBM sobre los que corre el Cobol tienen unos niveles de seguridad, eficiencia y funcionamiento a prueba de fallos absolutamente espectaculares, y no se equivoque nadie, son sistemas que se modernizan igual que todo lo demás, bueno, quizás algo más lentos, pero se modernizan, aunque los programas que llevan 40 años corriendo en ellos y que son el núcleo y corazón de auténticas corporaciones enormes no sean fácilmente modificables, ese "nivel" de integración con la lógica del negocio se ha perdido, cuando un programador actual de cobol y java pasan en 90% de su tiempo peleándose contra sus propias limitaciones y las de los lenguajes que utilizan (Java, sin ir más lejos, da trabajo en sí mismo, entre arreglos de fallos, softwares deficientes y demás, sin entrar siquiera en la lógica de negocio a grandes rasgos o ser capaz de presentar algo presentable en pantalla).
Me lo dijo una vez un jefe de informática de una empresa, El Cobol a nadie le gusta excesivamente, se ve antiguo y feo, pero funciona, joder que sí funciona, y el 90% de la lógica vital del negocio está en él. ¿Quién va a poner su trabajo en peligro por tener cuatro colorines más y acceso Web si no es 100% vital para la empresa? Sobretodo cuando el acceso Web lo puedes tener igualmente parcheando esos Coboles y buscando soluciones alternativas sin cambiar una línea del código "obsoleto", transformando el Java en un simple "frontend" del viejo y feo Cobol, que sigue siendo donde corre lo importante y que no puede fallar.
Os tocará la moral a los de Java, pero las cosas son como son.
#53 Y porque nos iba a tocar la moral. Aquí hay cosas diseñadas para realizar X.
A lo que voy, cualquiera que entienda de Java ni se plantea sustituir COBOL con JAVA. Es absurdo comparar 2 lenguajes diseñados para cosas diferentes. Soy de los que piensan q ya va tocando sustituir COBOL porque por mucho que diga este tío tiene que haber soluciones mejores, pero como ya han dicho por ahí a ver quién es el guapo que cambia algo que esta hiperdepurado y que se conoce tan bien que todos los fallos que da son predecibles y controlables. A lo anterior añadiremos el insignificante detalle de que esas aplicaciones manejan la pasta.
De todas formas de sustituirse jamás debería hacerse por JAVA. simplemente porque Java no está hecho para ese tipo de operaciones intensivas. Java está hecho para llegar a cualquier equipo informático; se diseñó para que algo hecho con él pudiera ejecutarse hasta en una tostadora. Pero eso tiene un precio llamado JVM q es pesada hasta decir basta y es de locos usar algo tan pesado para hacer operaciones sobre datos de forma intensiva.
En resumen, la discusion COBOL Java me parece tan absurda como decir que es mejor un deportivo que un camión. Ambos son vehículos pero cualquiera puede ver que no se diseñaron para lo mismo por lo tanto no se puede comparar.
Asique que se planteen cambiar COBOL. Que se tomen su tiempo en probar nuevas soluciones pero las tiene q haber mejores y mejorables fuera de COBOL. Eso si x su bien que dejen java para los frontales web y no para las transacciones sino van a tener q aflojar una pasta en maquinas.
#87 excelente explicación. Aunque discrepo con lo de dejar Java para los portales web, habiendo soluciones más sencillas,
#95 Supongo que esas soluciones mas sencillas pasan por php y similares. Bueno pues si y no y explico mi propia experiencia y mi opinión.
Mientras tengas contenido estático o "ligeramente" dinámico estoy de acuerdo. php tiene una curva de aprendizaje y desarrollo cojonuda y se ejecuta directamente en un apache con el modulo d php ahorrándote una máquina virtual. Además la depuración es muy cómoda al ahorrarte redespliegues. Esta situación de "semidinamicidad" se da en un porcentaje altísimo de las páginas web con lo cual php es algo muy muy a tener en cuenta y q no debe despreciarse para nada.
Sin embargo en una situación de páginas muy dinámicas. Con contenido sacado de diversas BBDD, con muchas funcionalidades dependientes unas de otras, con datos sacados de grandes sistemas transaccionales (como los sistemas COBOL) y otro tipo de paginas con un negocio complejo y laborioso veo un poco suicida meterse con php. Básicamente ante un uso de datos dinámicos tan grandes la estructura interna que da la POO es lo idóneo. Los intentos que he visto de hacer estas cosas en php acaban cn programas inmantenibles, con apaños de por medio para entenderse y cruzar bien todo lo que te llega del resto de sistemas, veo complicao hacer que se entiendan con sistemas heterogeneos en general y ademas son malamente evolucionables debido a esa falta de estructura (o estructura mas flexible) que tan sencillo hace a php.
Además hay que contar que el apache y similares están mas bien diseñados para gestionar peticiones a la velocidad del rayo dando una puerta de acceso al servidor realmente muy segura pero no me parece una bestia de carga precisamente. Si lo que tienes son muchas piedras (datos) que cargar y mover de un lado a otro hasta que las entregas al usuario compensa el peso de una maquina virtual.
De todas formas al final muchas veces la solución que se tiene es hacer la parte estática y con un negocio sencillote en php para tener algo realmente rápido y el negocio complejo en java. De cara al usuario no hay ninguna diferencia pero estás equlibrando el trabajo y consiguiendo un sistema mas robusto.
Si discrepas de mi opinión me encantaría saber la tuya.
#87 #54 Lo de que Java está diseñado para correr en electrodomésticos es más viejo que Matusalén: Java hace años que está diseñado para correr en mainframes y soportar cargas de trabajo bestiales. Precisamente cuando hablamos de mainframes lo que ocupa la MV es una nadería: ¿a quién le importa que cualquiera programa necesite de 30MB para arriba cuando todo lo que tiene que soportar ocupa 16GB en RAM? Yo estoy manteniendo un sistema que no para de evolucionar desde hace 20 años, decenas de miles de clases que no paramos de modificar y testear... y funciona. Y está muy relacionado con el mundo de los bancos en cuanto a que tenemos decenas de miles de usuarios y transacciones monetarias.
Y para nada esta noticia me afecta a la moral... bueno, sí, pero positivamente: si se quejan de que Java es mucho más compacto que COBOL y caben más errores en menos líneas, ahora me puedo reír de los que me hablan de Python o Ruby para cosas grandes, porque Java les parece demasiado "explícito" (verbosed)
Que los bancos tengan un departamente de software tan cutre que no sean capaces de hacer una migración como dios manda es una cosa, y otra que COBOL sea lo mejor hoy día para estos sistemas. COBOL sigue siendo un sistema válido... pero NADIE empieza hoy día un proyecto desde cero en COBOL.
#53 no te mosquees pero que tamaño y coste de hardware tienen esos mainframes de IBM de los que hablas? Joder que precio por precio se doblan costes y se habla de eficiencia cuando te meten RAM y procesadores para aburrir a precio de oro, que no nos vamos a enfadar que puede haber una convivencia, pero me hace gracia lo de la seguridad esta claro que vas a tener más problemas en un entorno cliente servidor que en un Host bien cerradito.
"Y agrega que, para superar los fallos y defectos, los bancos deben analizar su código y averiguar exactamente cómo funciona. El científico considera que el problema de la industria financiera es que los sistemas se crearon hace años y muchos operan con poca comprensión de por qué ha sido diseñado de esta manera".
Está pasando. El ser humano involuciona, ya no se entiende la tecnología, es como si las cosas funcionaran de un modo mágico. la gente de dentro de 100 años hablará de las maravillas de los Antiguos, y se maravillarán de ellas aunque hayan dejado de funcionar por falta de energía o de mantenimiento
#30 no necesito que pasen 100 años para hablar maravillas de los antiguos pues ya lo hago. Vamos! como no se puede hablar maravillas de quienes construyeron la stargate?
COBOL dominará el mundo, y tengo la prueba: Los terminators están programados en COBOL
#33 Es verdad, se ve claramente en la foto de 3 pixeles que has puesto
#33 Foto en ultraresolución, así sí se ve bien claro.
#33 el efecto 3D de tu imagen es acojonante, parece que el Terminator va a salir de la pantalla
Las únicas migraciones que conozco son a SAP y de una parte muy pequeña. Migrar todo el COBOL a otra cosa requiere una inversión de dimensiones Bíblicas, queda COBOL para días
No he entendido ningún comentario
#41 Cobolizate hombre, si es que no vas a la ultima.
#46 COBOL es Hipster
Un gran problema es que las grandes TIC no invierten en formación porque todo está "en google". No, amigos, NO TODO está en google.
#4 Las españolas, querrás decir
#39 Es que ensamblador es irreemplazable. A no se que quieras reinventar la rueda y hacer lo mismo con otro nombre.
#4 No todo está en Google, pero si no está en Google no existe
¡Y mi madre diciendome todos los días que tire los apuntes y los libros viejos! ¿¡Quién tiene razón ahora?! ¡¡¿Quiénnn?!
Java nuevo? Si nacio en 1995!!! eso es el jurasico de la informatica.
Que digan que no tienen ni puta idea de como funcionan los programas que tienen hechos, o que costaria mucho la creacion de cero de programas mas modernos, pero que no digan sandeces.
De hecho, el mantener COBOL porque no tienen ni puta idea de como funcionan sus sistemas les hace a la larga tener muchos mas problemas. La migracion a java les puede durar 5 o 6 años, con un buen plan y gastandose el dinero en buenos equipos (no en consultoras). Mantener COBOL les va a salir mucho mas caro y problematico a la larga. Pero ellos sabran (o quiza el problema es que no saben...)
muahahahaha, la venganza de los coboleros!!! Yo hice un esfuerzo de pasarme de Cobol a Java pero mi cerebro no lo resistió. En cambio, con el PHP triunfé... Mi profesor de Java, un tipo que llevaba más de 10 años trabajando con él decía que era "una porquería de lenguaje". Lo decía medio en broma, pero yo he llevado proyectos con una parte en Java y una parte en Cobol y la diferencia entre los dos equipos de programadores era considerable, tanto en rapidez como en eficiencia. La complejidad del Java para hacer cosas sencillas es muy incómoda.
Y la justificación de la P.O.O. no me sirve, hay otros lenguajes orientados a objetos... incluido el PHP. Tarde o temprano las grandes empresas se darán cuenta de los costes brutales que están asumiendo por apostar por el Java y se pasaran a PHP, Ruby, Python...
#58 "Mantener COBOL les va a salir mucho mas caro y problematico a la larga"... por qué? Eso me suena a dogma que no se puede demostrar. En un gran empresa, Java tiene sentido para lo que no puedas hacer en Cobol (servicios web, comunicación via xml, ...), y aun así creo que hay opciones más sencillas.
#58 Sin ofender, pero se nota que nunca has trabajado en entorno bancario, no te haces una idea del tamaño de esos sistemas
Bueno, no sé, pero decir que Java es un lenguaje nuevo estaría bien si viviéramos en 1995-2000.
Es como decir que NFS (también ideado por Sun Microsystems, empresa que desarrolló Java) es algo nuevo, y seguramente sus sistemas lo utilicen para sus sistemas de archivos distribuidos junto con VFS. Todo de 1985.
Si para que algo esté asentado y sin fallos de seguridad debe llevar 54 años en marcha (COBOL ideado en 1959), difícilmente lo llevan, porque incluso los compiladores de COBOL tienen revisiones, y digamos que mucho mantenimiento no tienen por lo que la calidad del ensamblador generado puede que no sea la misma que se pueda obtener con Java o C/C++. De hecho la última versión estable de COBOL data del 2002, a la cual se añadió orientación a objetos, con los numerosos cambios que requiere.
http://en.wikipedia.org/wiki/COBOL
Esto me parece propaganda para contrarrestar lo que se viene diciendo últimamente sobre la inestabilidad de los sistemas bancarios, sobre todo a raíz de la huelga de HP.
La realidad es que sólo los sistemas internos "críticos" son programados en COBOL, el resto se hace en Java (sobre todo los diversos sistemas de banca on-line), y la totalidad de los sistemas son hechos por programadores "Junior".
Primera norma: si funciona no lo toques.
¡Ahora entiendo la crisis! ¡Todo ha sido un error informático!
Los Coboleros persistimos aunque hace años nos llamaban obsoletos ... y cuando explicas en que programas la gente pone cara de cirscunstancia, sisi, pero seguimos teniendo curro...!
#60 #62 no sé si tenéis el gusto de conoceros
Ya hace un tiempo que vi este artículo: cobol nos sobrevivirá a todos:
http://www.itworld.com/career/341879/cobol-will-outlive-us-all
No es ni cuestión de pasta, es cuestión de huevos. Yo desde luego jamás me metería en la migración de ninguno de esos sistemas, antes prefiero mendigar
Cobol son los padres
ya, pero si no llega a ser por C, ahora mismo se llamaría OBOL
Una de las razones fundamentales de la duración del Cobol son los equipos donde funcionar, por mas que se hable maravillas de Linux/Unix jamas estarán a la altura de la estabilidad del VMS, hoy OS9, y pasa lo mismo con el Hardware, por mucho que veamos clusters y datacenters nunca darán el servicio de un Mainframe, veo complicado, casi imposible que un Intel i7 sea capaz de dar el mismo servicio que ha dado un IBM 4381 durante años
#51
Si haces como los mainfraneros, es decir, te prohíbo el SQL dinámico, te corto todas las transacciones que duren más de 2 segundos de CPU, para los sistemas 7x24 todos los días dos horas para hacer la copia de seguridad, te hago yo estable hasta un Windows Vista.
#51 He votado negativo sin querer! Perdón, te lo compenso en otro.
Los bancos quieren magia. Software ultrapotente a coste 0.
los bancos si tienen problema grave de seguridad.... algunos chupaderos de la política en su dirección, es mas destructivo que el peor virus informático
a este ritmo también llegare usar de nuevo el de ensamblador
#39 Que grande el libro de trucos de la megadrive!!!
#39 El libro de Dune en medio de los libros de informática... el paradigma del friki
Llevo años riendome de cobol
Parece que al final me tendré que tragar mi orgullo y aprender cobol
(con lo feliz que era con C, Java, PHP, Python, Nodejs, ...)
Vaya, qué casualidad que me pasaran este vídeo ayer,
Respecto a mi anterior comentario en esta noticia, Java puede compilarse a código nativo gracias a GCJ.
Otra cosa distinta es el bytecode para una JVM.
Vale, pero de que colonia.
El mundo no se acaba con Java, también existen otros quizá más apropiados.
COBOL roolz!!
Eso de que los bancos van a seguir con Cobol... el Banco Santander está estudiando implantar Open Cobol que genera interfaces en C, C++ y Java a través del código original de Cobol, si bien tienen que realizar labores de rendimiento para ver si ejecutan las tareas a la misma velocidad, si realmente funciona bien, el objetivo del banco es quitarse las costosas licencias de Cobol e intentar integrarlo con el resto de sistemas
Al parecer el objetivo es empezar por un banco alemán si las pruebas de rendimiento obtienen los frutos esperados
#50 Trabajo en el Santander. Créeme, van a seguir con COBOL muuuuchos años.
Escala?