Barrapunto

Si funciona bien me parece realmente impresionante.

Ahora, no quiero pensar en mantener el código que salga de aquello, porque dudo mucho que organice el código según metodologías modernas.

Tal vez sea más fácil mantener el código COBOL. En cualquier caso, realizar una aplicación de este tipo tiene un mérito más que reseñable.

Pues eso, que ya no tendrá ningún mérito ganar ese tipo de concurso >:)

Poder hacer algo no es lo mismo que querer hacer algo (o que hacer algo sirva para nada).

No quiero ni ver el impacto de cambiar de cobol a java para los rendimientos.

Un lenguaje orientado a servicios transaccionales a la antigua .... ¿traducido a java?
Por dioooooossssss.

Otro ejemplo de inutilidad, salvo que en una inutilidad anterior se utilizase cobol para hacer un simple programa de gestion no transaccional y aislado.

Creo que es interesante recordar que .NET lo soporta: Cobol.NET [barrapunto.com]. Me pregunto si además correrá en Mono.

La verdad que a mi me ha llamado bastante la atención y a cualquiera que tenga dos dedos de frente y esté en una empresa con entorno mainframe, debería por lo menos "picarle" la curiosidad. Yo llevo años trabajando en entornos bancarios y Aquí todo es mainframe salvo los "bichos raros" que estamos en la parte de presentación, y trabajamos con Java, C++, aplicaciones web, etc. Los costes del mainframe son inmensos, os lo puedo asegurar. Tener un entorno para pruebas, o un entorno para formación, por ejemplo, son enormemente caros de mantener. Si esto funciona medianamente bien, no lo pondría en real, pero sí puede ser un punto de partida para montar entornos intermedios que ahora mismo cuesta un pastizal mantener. Saludos a todos ;-)

Aparecerá otra herramienta que migre aplicaciones Java a lo que esté en ese momento de moda :P

Mas que una comparativa de técnologías de a ver cual es mejor, creo que se trata de un:

Si funciona, no lo toques.

Así de simple. No es que Cobol y sus mainframes sean lo mejor, es que cambiar toda una infraestructura montada, el código muy maduro que tiene (errores mínimos), y, a parte del coste considerable del cambio (equipos, reprogramación, y amplias pruebas), se corre el riesgo de tener un código joven y con alta probabilidad de errores, un riesgo que las entidades no se pueden permitir.

Y claro que Java es muy capaz de hacer lo mismo que Cobol, y mejor, claro. Incluso me atrevería a decir que bajo una infraestructura más barata. Pero el problema es lo comentado, el miedo al cambio por el riesgo que se asumiría.

Existen alternativas a COBOL + Mainframe. Infodesa implementaba un producto muy interesante llamado Servidor Financiero, que adaptaban a tus necesidades específicas; lo usa bastante gente http://www.infodesa.es/index.php?option=com_conten t&task=view&id=61&Itemid=82 [infodesa.es] montado sobre clusters HP-UX y que tras probar este año es compatible casi 100% con la última versión de REd Hat Linux. El problema es que los costes de las máquinas y las licencias de todo el software necesario no alejan los costes tanto como pudiera parecer. Si se usa Linux los costes se reducen por la baja del coste del hardware, pero el soporte es bastante pobre. Eso unido al coste elevado de migrar y adaptar todo un sistema monolítico que lleva años funcionando con una solidez apabullante hace que muchos clientes rehuyan de la idea. Yo pierdo mi tiempo trabajando en un Z890 uqe convive con parte de Servidor financiero corriendo sobre HP y sobre Linux. Y de momento solo el negro lo hace todo y con una menor tasa de errores. Mañana Dios dirá, y sería curioso ver ese Java sobre un Zseries preparado para apps Java, que los hay. Además mi CICS es mas bonito que tu Garbage Collector ;-p

Para errameientas similares, Fujitsu, desde sus versiones antiguas se puede pasar a .net con muy poca modificación. Claro que el cobol de Fujitsu es un poco demasiado especial.

De todas formas, lo primero que va a impacatar es como un programa de apenas 1 Mb en RAM corriendo en cobol pasa a mas de 100 en Java.

No se porque esa obsesion por acabar de arrinconar al Cobol. Cierto que en standard la orientacion a objetos como si no existiera o nunca se haya usado, que las variables, entre que se declaran al ppio., son globales y que suelen tener nombres peculiares son dificiles de rastrear y que el debugger, en el caso de RM-Cobol es inutilizable, si has catado las excelencias de Visual Studio, pero creo que todo esto se solucionaria si se dispusiera de un buen IDE, cosa que en mi caso y de RMCobol se reduce a Notepad++ y colorines para secciones e instrucciones.

En definitiva, creo que mas vale dedicar este tiempo de desarrollo a aprender Cobol bien, porque, en cualquiera de los casos y dado el caso de las aplicaciones donde Cobol está funcionando, el dominio de Cobol va a ser imprescindible para saber si la conversion a Java hace lo que tiene que hacer.

Osease, que una barita magica no va a existir en la vida.