studio - ¿De verdad hay COBOL en.NET?

visual cobol for eclipse (6)

Estuve revisando la página de Microsoft Visual Studio justo ahora y en la barra lateral de anuncios repentinamente vi un anuncio increíble:

"Net Express es un entorno de desarrollo de COBOL para extender los procesos de negocio principales al .NET Framework y otras plataformas distribuidas".

Por supuesto, seguí el enlace y encontré una empresa que hace esto, pero ¿hay lugares que todavía usan COBOL? ¿Alguien realmente usa COBOL en .NET frameworks?

Editar: Gracias a todos por la información a continuación, ¡definitivamente aprendí algo hoy!

Creo que el escenario más común es la interoperabilidad, por ejemplo, las aplicaciones de Windows y ASP.NET que se comunican con las aplicaciones de COBOL / CICS y viceversa.

Hace algunos años participé en un proyecto de este tipo para un importante banco de mi país, y puedo imaginar que esto sería bastante común para cualquier banco que tenga más de 40 años de TI bajo su cinturón.

El artículo de Wikipedia me sorprendió:

Los programas COBOL se utilizan globalmente en agencias gubernamentales y militares, en empresas comerciales y en sistemas operativos como z / OS de IBM, Windows de Microsoft y familias POSIX (Unix / Linux, etc.). En 1997, el Grupo Gartner informó que el 80% de los negocios del mundo funcionaba en COBOL con más de 200 mil millones de líneas de código en existencia y con un estimado de 5 mil millones de líneas de código nuevo anualmente.

http://en.wikipedia.org/wiki/COBOL

Pensé que Cobol es "madera". No es cierto. Por cierto, Fujitsu NetCOBOL para .NET y Micro Focus Net Express® con .NET son implementaciones bastante completas. ¿Tal vez deberíamos estudiar este idioma y encontrar un buen trabajo con un gran salario después? :)

COBOL es un nicho. Un nicho agradable, cómodo y rentable. Probablemente (antes o después) se volverá inexistente, pero en este momento todavía está allí. Aquí, varias grandes organizaciones bancarias tienen sus sistemas principales desarrollados en COBOL. ¡Esto no es solo mantenimiento, sino también desarrollo!

Ha existido por 50 años más o menos, cada 10 años alguien lo anuncia muerto, pero todavía se cuelga.

Realmente aprendí a codificar 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. No lo han tocado por 15 años sin embargo.

COBOL es el lenguaje de procesamiento financiero por lotes por excelencia. Correctamente estructurado, puede hacer lo que mejor hace, procesar grandes cantidades de datos financieros, mejor que cualquier otra cosa. También es un lenguaje notablemente bueno para incrustar otros sistemas, a menudo operando como pegamento entre otros sistemas.

Piense en ello como una locomotora :-). En el siglo XIX todo el mundo solía viajar en tren porque era todo lo que teníamos, pero para la mayoría fue reemplazado por automóviles y aviones. Para mover grandes cantidades de carga pesada, aunque el sistema ferroviario sigue siendo el camino a seguir. A menudo no se ven locomotoras en la vida cotidiana, pero mantienen sus estaciones de energía funcionando con carbón.

Es notable que Lisp todavía tiene una posición similar en la codificación AI. Lo que sí encuentro interesante es que el otro miembro del grupo de los tres idiomas "grandes" de la década de 1960/70 - Fortran - ha disminuido más que los demás, que no es lo que yo hubiera esperado en ese momento. Sin embargo, todavía tenemos BASIC en gran medida, 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 muchos lugares que siguen haciendo COBOL aunque no necesariamente para .NET; todavía hacemos bastante 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 de COBOL (por ejemplo, Fujitsu) para las plataformas de Windows.

Micro Focus crea un paquete de desarrollo COBOL que está destinado sustancialmente a mantener aplicaciones heredadas de mainframe. Habla algo así como 20 dialectos de COBOL de varias plataformas y tiene una función de emulación CICS . Desde 2004 lo recomiendan para reemplazar cargas de trabajo de mainframe de hasta 400 MIPS más o menos. Teniendo en cuenta que aún podría comprar sistemas de mainframe con una calificació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 heredados de COBOL 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 envolturas RPC para varios protocolos como CORBA y SOAP.

Hace algunos 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 compatibles y ejecutará todas las funciones de emulación heredadas. Esto le permite colocar una GUI o front-end web (o una capa de servicios web) en una aplicación COBOL existente, preservando su inversión en la base de códigos existente. El front-end se puede escribir con casi cualquier herramienta de desarrollo que admita CLR. Desea utilizar la integración de C # / Formularios de Windows, MS Workflow Foundation, SSIS, IronPython, ASP.NET o CLR de SQL Server con su back-end de COBOL: olvídese.

Como tal, a menudo es una alternativa muy atractiva para una relectura y migración completa de una aplicación heredada.

Este tipo de trabajo representa una gran parte de su negocio, pero todavía hay nichos donde COBOL realmente hace un buen trabajo por derecho propio. Para muchos trabajos por lotes grandes abrir un archivo orientado a registros y procesarlo procesalmente es un buen paradigma para obtener una aplicación que sea simple, comprensible y rápida . Una vez leí una publicación (en Slashdot IIRC) en la que alguien estaba hablando sobre una aplicación COBOL que leía en un archivo de 35GB de reembolsos de tarjetas de crédito y la procesaba cada hora . Eso fue publicado hace mucho tiempo, en algún momento de la década de 1990, en un momento en que 35 GB era considerablemente más grande que la capacidad de disco de la mayoría de las PC.

Obtener un RDMBS para cargar en bloque y procesar 35 GB de datos (100-200 millones de registros en una estimación) en una hora no es necesariamente un trabajo trivial, incluso en hardware moderno. A menudo, obtener el rendimiento de SQL requiere que adoptes un enfoque un tanto oblicuo con el procesamiento, lo que puede oscurecer el significado del código; el SQL altamente sintonizado puede ser bastante ''solo de escritura''.

COBOL se ha utilizado en este tipo de aplicaciones durante aproximadamente 50 años y es una tecnología madura, bien entendida y confiable que realmente lo hace bastante bien.