Este grupo de especialistas pasados algunos días de investigación y recopilación de de información, encontramos la solución, nuestro deseo es que te sea útil para tu proyecto.
Solución:
Micro Focus crea una suite de desarrollo COBOL que tiene como objetivo principal mantener las aplicaciones de mainframe heredadas. Habla algo así como 20 dialectos de COBOL de varias plataformas y tiene una función de emulación CICS. A partir de 2004, lo recomiendan para reemplazar cargas de trabajo de mainframe de hasta 400 MIPS aproximadamente. Teniendo en cuenta que todavía se podían comprar sistemas mainframe con una clasificación de 22 MIPS de Amdahl a principios de la década de 1990, 400 MIPS en un mainframe es una carga de trabajo bastante considerable.
La integración de back-ends COBOL heredados en front-ends modernos es un gran negocio. Existe un ecosistema bastante importante de software de emulación de terminal, raspadores de pantalla, bibliotecas de interfaz y envoltorios RPC para varios protocolos como CORBA y SOAP.
Hace unos años, Micro Focus presentó un compilador COBOL .NET que le permite ejecutar aplicaciones COBOL en un back-end CLR. Puede compilar cualquiera de los dialectos admitidos y ejecutará todas las funciones de emulación heredadas. Esto le permite colocar una GUI o un front-end web (o una capa de servicios web) en una aplicación COBOL existente, preservando su inversión en la base de código existente. El front-end se puede escribir con prácticamente cualquier herramienta de desarrollo que admita CLR. Desea utilizar la integración de C#/Windows Forms, MS Workflow Foundation, SSIS, IronPython, ASP.NET o SQL Server CLR con su back-end de COBOL: déjese llevar.
Como tal, a menudo es una alternativa muy atractiva a una reescritura completa y migración de una aplicación heredada.
Este tipo de trabajo representa una gran parte de su negocio, pero todavía hay nichos en los que COBOL realmente hace un buen trabajo por derecho propio. Para muchos trabajos por lotes grandes, abrir un archivo orientado a registros y procesarlo de manera procesal es un buen paradigma para obtener una aplicación que sea simple, comprensible y rápido. Una vez leí una publicación (en Slashdot IIRC) en la que alguien hablaba de una aplicación COBOL que leía un archivo de 35 GB de reembolsos de tarjetas de crédito y lo procesaba. cada hora. Eso se publicó hace mucho tiempo, en algún momento de la década de 1990, en un momento en que 35 GB eran considerablemente más grandes que la capacidad de disco de la mayoría de las PC.
Conseguir que un RDMBS cargue y procese de forma masiva 35 GB de datos (entre 100 y 200 millones de registros aproximados) en una hora no es necesariamente un trabajo trivial, incluso en hardware moderno. A menudo, obtener el rendimiento de SQL requiere que adopte un enfoque algo oblicuo para el procesamiento, lo que puede oscurecer el significado del código; SQL altamente ajustado puede ser bastante ‘solo escritura’.
COBOL se ha utilizado en este tipo de aplicación durante aproximadamente 50 años y es una tecnología madura, bien entendida y confiable que en realidad lo hace bastante bien.
Realmente me inicié en la codificación COBOL: aprendí en Fortran, Pascal y C, pero pasé la mayor parte de mis primeros 5 años codificando profesionalmente en COBOL en IBM/390s. Sin embargo, no lo he tocado en 15 años.
COBOL es el lenguaje de procesamiento financiero por lotes por excelencia. Bien estructurado, puede hacer lo que mejor sabe hacer: procesar grandes cantidades de datos financieros, mejor que cualquier otra cosa. También es un lenguaje notablemente bueno para integrar otros sistemas, a menudo opera como un pegamento entre otros sistemas.
Piense en ello como una locomotora :-). En el siglo XIX todo el mundo viajaba en tren porque era todo lo que teníamos, pero para la mayoría eso fue reemplazado por automóviles y aviones. Para mover grandes cantidades de carga pesada, el sistema ferroviario sigue siendo el camino a seguir. No sueles ver locomotoras en la vida cotidiana, pero mantienen tus centrales eléctricas funcionando con carbón.
Es notable que Lisp todavía tiene una posición similar en la codificación de IA. Lo que me parece interesante es que el otro miembro del grupo de los tres idiomas ‘grandes’ de los años 60/70, Fortran, ha disminuido más que los demás, lo que no es lo que esperaba en ese momento. Sin embargo, todavía tenemos BASIC a lo grande, que es efectivamente el hijo bastardo de Fortran, por lo que podría decirse que los tres están tan vivos y coleando como siempre.
Rob, hay un lote de lugares que siguen haciendo COBOL aunque no necesariamente para .NET; todavía hacemos un poco de desarrollo de mainframe y la gran mayoría de las aplicaciones financieras todavía están escritas en COBOL interactuando con CICS.
Además, aún puede obtener compiladores COBOL (p. ej., Fujitsu) para las plataformas Windows.