Tengo una tarea para convertir el código de COBOL a .NET. ¿Hay algún convertidor disponible? Estoy tratando de entender el código COBOL en el nivel alto. Tengo problemas para entender el código COBOL. ¿Hay generadores de diagrama de flujo? Agradezco cualquier ayuda.migrar código de COBOL
Gracias ..
Esto no es una tarea fácil. COBOL tiene ideas fundamentales sobre tipos de datos que no se ajustan bien con el framework .NET orientado a objetos (por ejemplo, en COBOL, todos los tipos de datos están representados en términos de búferes de tamaño fijo) y, en particular, la forma en que los grupos y matrices no bien a las clases .NET.
Creo que hay compiladores de COBOL que realmente pueden compilar el bytecode de .NET, pero tendrían sus propias bibliotecas de tiempo de ejecución para administrar todo eso. Puede valer la pena mirar uno de estos compiladores y simplemente dejar el código heredado en COBOL.
Aparte de eso, la traducción línea por línea probablemente no sea posible. Mire el código en un nivel superior y traduzca bloques de código a la vez (por ejemplo, en el nivel de procedimiento o incluso más).
por curiosidad ¿qué bloques de código serían de un nivel más alto que "Procedimiento"? – kloucks
@kloucks: en realidad no hay un "procedimiento" real en COBOL. Un programa COBOL se divide en SECCIONES, PÁRRAFOS y ORACIONES. UN PÁRRAFO es como un método o procedimiento y una SECCIÓN es como un módulo. Sin embargo, es posible escribir su COBOL de modo que no funcione de esa manera, por lo que la traducción automática es muy difícil. –
Pensé que se refería a una estructura de aplicación tipificada por esta situación [http://publib.boulder.ibm.com/infocenter/db2luw/v8/topic/com.ibm.db2.udb.doc/ad/c0010381.htm ] que acepto sería difícil de traducir a través de un analizador. traducir un solo programa generalmente solo es difícil cuando hay mucha lógica guiada por GOTO, un programa altamente "estructurado" a menudo es bastante fácil. – kloucks
Micro Focus y Fujitsu tienen productos COBOL que funcionan con .NET. Micro Focus le permite descargar una versión de prueba del producto, mientras que el sitio de Fujitsu NetCOBOL tiene una serie de artículos y estudios de casos.
Fujitsu http://www.netcobol.com/products/Fujitsu-NetCOBOL-for-.NET/overview
Migración de sistemas de software de un idioma o el entorno operativo a otro es siempre un desafío. Aquí están algunas cosas a considerar:
Ha habido proyectos exitosos que migraron COBOL directamente a Java. Ver naca. Sin embargo, el resultado final es solamente algo de su madre (u otro programador de COBOL) podría amar, see this discussion
En general yo sería sospechoso de cualquier demanda de productos o la fabricación de herramientas para convertir su legado de COBOL sistema en cualquier cosa menos otra versión de COBOL (por ejemplo, COBOL.net). Con este fin todavía terminan con lo que es esencialmente un sistema COBOL. Si este enfoque es aceptable, entonces usted puede querer revisar este white paper de Micro Focus.
En mi humilde opinión, su mejor apuesta para reemplazar COBOL es volver a diseñar su sistema. Si alguna vez encuentras una bala de plata para llegar desde donde estás a donde quieres estar - escribe un libro, conviértete en un consultor y gana muchos millones de dólares.
Lamento haber proporcionado una respuesta tan negativa, pero si está trabajando con algo pero un sistema legado trivial, el problema va a ser cualquier cosa menos trivial de resolver.
Nota: No moleste con el diagrama de flujo del sistema existente. Intente obtener un control sobre la entrada/salida del proceso y el programa para programar el flujo y la transformación de datos. Necesita comprender la función comercial aquí, no una implementación específica de la misma.
[Nota: Yo trabajo para Micro Focus]
Hola
En realidad, haciendo que las aplicaciones COBOL disponibles en el marco .NET es bastante sencillo (contrariamente a la afirmación hecha en una de las respuestas anteriores). Fujitsu y Micro Focus tienen compiladores COBOL que pueden crear código ILASM para su ejecución en el CLR.
Micro Focus Visual COBOL (http://www.microfocus.com/visualcobol) hace que sea particularmente fácil implementar COBOL tradicional de procedimiento como código administrado con soporte completo para tipos de datos COBOL, sistemas de archivos, etc. También incluye una sintaxis OO COBOL actualizada que quita una gran cantidad de la verbosidad & complejidad de la sintaxis para ser muy fácil de escribir código COBOL basado en ejemplos de C#. Su enfoque único también facilita el uso de todas las herramientas de Visual Studio como IntelliSense.
La pregunta original mencionó "convertir" y recomendaría encarecidamente que no se adopte ningún enfoque que requiera que el código fuente se convierta a algún otro idioma antes de ser utilizado en un entorno .NET. Es muy poco probable que la cantidad de esfuerzo y riesgo involucrados valga los beneficios acumulados. Por el contrario, mantener el código en COBOL mantiene el código de trabajo existente y permite la opción de implementarlo en otras plataformas en el futuro. Por ejemplo, ¿qué tal tener un solo conjunto de código fuente y tener la opción de implementar en .NET como un idioma nativo y en un entorno Java sin cambiar una línea de código fuente?
Le recomiendo que obtenga una copia de prueba de Visual COBOL desde el enlace de arriba y vea cómo puede usar su código existente en .NET sin realizar ningún cambio.
No soy tan positivo acerca de "no hay beneficios de convertir el código fuente". Sin embargo, estoy totalmente de acuerdo con Mark en que si su organización tiene habilidades COBOL existentes, una implementación .NET de sus aplicaciones COBOL tiene MUCHO sentido, y es una opción que debe considerarse seriamente antes de pensar en una conversión de idioma. –
Existen muchos mecanismos para convertir COBOL a entornos escalables modernos, como .NET o Java.
La primera es una migración a un nuevo entorno con el guardado del código COBOL existente con algunas modificaciones menores (NET Microfocus COBOL);
La segunda es una migración a una nueva plataforma con simulación de instrucciones y construcciones COBOL.Cuando hay algunas bibliotecas NET/Java adicionales para simular alguna lógica COBOL específica: ACCEPT va a NETLibrary.Accept y así sucesivamente.
El tercer enfoque es el más valioso, cuando se migra a un código NETO/Java "puro" con todos los beneficios del nuevo entorno. Se puede mantener y desarrollar fácilmente en el futuro.
Sin embargo, la experiencia y los kits de herramientas únicos son necesarios para este enfoque, y solo hay unos pocos jugadores en el mercado global que pueden ayudarlo en este caso. Si hablamos de migración automática, la cantidad de jugadores disminuye mucho y, lamentablemente para usted, tiene que pagar por las tecnologías y herramientas específicas (como la nuestra).
Sin embargo, es una mejor idea invertir su dinero en su crecimiento futuro en el entorno moderno, que gastar su dinero en la "simulación" de tecnologías antiguas.
Solía haber generadores de diagrama de flujo en el mercado para los programas COBOL, pero a decir verdad eran a menudo bastante inútiles a menos que el código que les suministró se ajustara a unos estándares muy rígidos; simplemente reserve un día para aprender a leer el código no es muy dificil – kloucks
Buena oportunidad para cerrar esto, fuera del tema. solicitud de herramienta. No puedo, como lo señalé para el cierre hace algunos meses :-) –
Woohoo. Puedo votar para cerrar esto nuevamente. –