Coincidiendo con el 50 aniversario de COBOL, leo en Barrapunto que el Proyecto NACA permite migrar aplicaciones COBOL completas a Java de forma completamente automática. La empresa que lo ha desarrollado, ha publicado las herramientas NacaTrans, NacaRT y NacaRTTest con licencia GPL.
#3 ¿tu has visto el código java generado por una herramienta de éstas?
El problema es que no lo puede mantener un programador Java ni programador COBOL.
Imagínate una programación lineal escrito en Java... pues éste es el código que vas a obtener.
#3 el problema es que la vida avanza, y los bancos también lo notan. Es cierto que la máxima es si funciona no lo toques, pero, ¿qué haces cuando hay que ampliar algo? O cambiarlo para adaptarse a algo nuevo, o añadir funcionalidades que antes no tenían sentido o no existían o, simplemente, la tecnología de hace 20 años no lo permitía. En ese momento, que ocurre casi a diario, hay que tomar la decisión: COBOL u otro lenguaje con una pasarela de comunicación entre el sistema viejo y el nuevo módulo.
Actualemente la segunda opción suele ser la más llevadera en tiempo, dinero y robustez, pero para eso hacen falta profesionales con capacidad para ambos lenguajes (COBOL y el "moderno", que no todo es Java en esta vida).
No creais que los bancos son entes cuyos sistemas no se tocan ni se cambian en 15 años. Es un sector que evoluciona mucho y muy rápido. Vale que aún se vean cajeros (pocos) con WinNT e incluso hace unos años aún había algún OS/2, pero las entrañas de los sistemas, aún manteniendo el código de hace dos décadas, deben cambiar y crecer casi a diario. ¿O acaso imagináis que todas las transacciones del BBVA o del Santander pasasen por un sólo mainframe con cintas de acceso secuencial?
En cuanto al migrador de código... ciertamente lo veo complicado que de algo decente para trabajar con ello después, pero también hay que tener en cuenta que un programa COBOL, salvo los GOTO, tiene una estructura muy sencilla, y además se solía ser muy rígido en el cómo hacer las cosas, por lo que no sería tan complicado (¡no quiero decir que yo lo hiciera en una tarde!). #6 piensa que al ser estructuras muy cerradas y constantes, instrucciones muy sencillas, etc... podría hacerse la migración a una nueva aplicación usando POO y lo que quieras. Cierto que el código puede ser enrevesado, feo, poco eficiente... vamos, código guarro, pero oye, es un paso, ¿no?
Los bancos no migran sus sistemas cobol a otra cosa porque saben que el sistema actual lo tienen depurado y "libre de errores", no creo que se fíen de un software que lo hace automáticamente..
#6 Independientemente de la codificación que genere, no puede hacer milagros por mucho que intente optimizar, no va a generar un código tan fiable como el original.
Ademas, por muy bien que esté desarrollado el servidor de aplicaciones XXXXX (substituye esto por el que quieras), este no esta libre de bugs y la aplicación generada menos todavía.
sinceramente, dudo que vaya a aplicarse a corto plazo, primero porque dudo que funcione correctamente, sobre todo al ser una aplicación nueva, y segundo porque a ver quién es el que tiene cojones de empezar a migrar todas las aplicaciones de por ejemplo, un banco o el corte ingles, de cobol a java
Es la misma mentira que te cuentan cuando te dicen "si, con la tecnologia XXX pintas los botones, unes las flechas y te hace el programa sin escribir codigo". Una mierda como Australia de grande!
#3 los bancos difícilmente migrarán, pero COBOL no solo se utiliza en bancos.
Actualmente hay muchos productos de software con 20-25 años que se siguen manteniendo. Funcionan, pero se tienen que "tocar" para añadir funcionalidades y la disponibilidad de programadores COBOL no es la misma que de programadores JAVA.
Cualquier ayuda para la migración de software COBOL a otros entornos es muy bienvenida en algunas empresas y sobretodo en algunos de los clientes de estas empresas
Comentarios
#3 ¿tu has visto el código java generado por una herramienta de éstas?
El problema es que no lo puede mantener un programador Java ni programador COBOL.
Imagínate una programación lineal escrito en Java... pues éste es el código que vas a obtener.
#3 el problema es que la vida avanza, y los bancos también lo notan. Es cierto que la máxima es si funciona no lo toques, pero, ¿qué haces cuando hay que ampliar algo? O cambiarlo para adaptarse a algo nuevo, o añadir funcionalidades que antes no tenían sentido o no existían o, simplemente, la tecnología de hace 20 años no lo permitía. En ese momento, que ocurre casi a diario, hay que tomar la decisión: COBOL u otro lenguaje con una pasarela de comunicación entre el sistema viejo y el nuevo módulo.
Actualemente la segunda opción suele ser la más llevadera en tiempo, dinero y robustez, pero para eso hacen falta profesionales con capacidad para ambos lenguajes (COBOL y el "moderno", que no todo es Java en esta vida).
No creais que los bancos son entes cuyos sistemas no se tocan ni se cambian en 15 años. Es un sector que evoluciona mucho y muy rápido. Vale que aún se vean cajeros (pocos) con WinNT e incluso hace unos años aún había algún OS/2, pero las entrañas de los sistemas, aún manteniendo el código de hace dos décadas, deben cambiar y crecer casi a diario. ¿O acaso imagináis que todas las transacciones del BBVA o del Santander pasasen por un sólo mainframe con cintas de acceso secuencial?
En cuanto al migrador de código... ciertamente lo veo complicado que de algo decente para trabajar con ello después, pero también hay que tener en cuenta que un programa COBOL, salvo los GOTO, tiene una estructura muy sencilla, y además se solía ser muy rígido en el cómo hacer las cosas, por lo que no sería tan complicado (¡no quiero decir que yo lo hiciera en una tarde!). #6 piensa que al ser estructuras muy cerradas y constantes, instrucciones muy sencillas, etc... podría hacerse la migración a una nueva aplicación usando POO y lo que quieras. Cierto que el código puede ser enrevesado, feo, poco eficiente... vamos, código guarro, pero oye, es un paso, ¿no?
Relacionadas:
Aprende COBOL y afronta la crisis con garantías
Aprende COBOL y afronta la crisis con garantías
logadmin.netCOBOL: 50 años de camino
COBOL: 50 años de camino
muycomputer.comAnda, esta noticia me interesa MUCHO.
Los bancos no migran sus sistemas cobol a otra cosa porque saben que el sistema actual lo tienen depurado y "libre de errores", no creo que se fíen de un software que lo hace automáticamente..
si funciona, NO LO TOQUES
Para otros sectores menos críticos, puede valer
#6 Independientemente de la codificación que genere, no puede hacer milagros por mucho que intente optimizar, no va a generar un código tan fiable como el original.
Ademas, por muy bien que esté desarrollado el servidor de aplicaciones XXXXX (substituye esto por el que quieras), este no esta libre de bugs y la aplicación generada menos todavía.
sinceramente, dudo que vaya a aplicarse a corto plazo, primero porque dudo que funcione correctamente, sobre todo al ser una aplicación nueva, y segundo porque a ver quién es el que tiene cojones de empezar a migrar todas las aplicaciones de por ejemplo, un banco o el corte ingles, de cobol a java
por cierto, estoy con #3
Es la misma mentira que te cuentan cuando te dicen "si, con la tecnologia XXX pintas los botones, unes las flechas y te hace el programa sin escribir codigo". Una mierda como Australia de grande!
#3 los bancos difícilmente migrarán, pero COBOL no solo se utiliza en bancos.
Actualmente hay muchos productos de software con 20-25 años que se siguen manteniendo. Funcionan, pero se tienen que "tocar" para añadir funcionalidades y la disponibilidad de programadores COBOL no es la misma que de programadores JAVA.
Cualquier ayuda para la migración de software COBOL a otros entornos es muy bienvenida en algunas empresas y sobretodo en algunos de los clientes de estas empresas
Punto positivo: Eso permitira que por los ojos de Terminator for fin se vea desfilar codigo algo mas actual.