Estoy constantemente leyendo acerca de cuánto código Cobol aún está en producción. Y la razón principal de que no se haya actualizado en un lenguaje más moderno es que tomaría demasiado tiempo/costaría demasiado.Modernize Legacy Cobol
Mi pregunta es: si hubiera una herramienta que convirtiera Cobol en, digamos, Java, ¿alguna organización lo consideraría útil? ¿O preferirían continuar manteniendo lo que saben que ya funciona?
Actualmente, un gran volumen del código COBOL (estimaría más del 90%) no puede ser comprobado.
Nadie sabe lo que realmente hace.
Saben que, como mínimo, hace el trabajo esperado la mayor parte del tiempo. Y cuando no lo hace, los errores son conocidos.
Peor aún, algunos porcentajes de COBOL son solo soluciones provisionales para errores en otras partes de COBOL.
Por lo tanto, si lo somete a un examen minucioso, descubrirá que no sabe lo que realmente está sucediendo.No puedes crear casos de prueba.
De hecho, verá que la mayoría de las organizaciones ni siquiera pueden ponerse de acuerdo sobre lo que es "correcto". Pero están dispuestos a comprometerse con lo que está disponible.
El costo y el riesgo de examinar el procesamiento central del negocio es impensable.
Uno siempre encontrará herramientas para convertir un idioma a otro - por lo general van por el término "compiladores".
Siempre hay una falla con los compiladores que tienen que realizar la tarea de convertir el código en el lenguaje X al lenguaje Y, especialmente cuando dicho código fue escrito por una persona. Esa deficiencia pasa por ser el hecho de que la readibilidad se pierde a menudo en el proceso de traducción. No hay garantía de que cualquier programador comprenda el código compilado de COBOL a Java, por lo que en realidad el costo de la traducción ha aumentado. De hecho, es difícil definir la legibilidad en dicho contexto.
La falta de legibilidad y comprensibilidad se traduce en la falta de conocimiento del comportamiento en tiempo de ejecución del código traducido. Además, no hay garantía de que las personas entiendan completamente el código original; seguramente entienden partes y piezas de ella.
Cualquier herramienta de conversión tendría riesgos asociados con ella, y el código resultante tendría que someterse a un lote de prueba.
Dado que muchos de estos sistemas se utilizan diariamente para hacer funcionar un negocio, mucho depende de la operación continua. Por lo tanto, no es solo "cuánto" o "qué tan caro", pero podemos confiar en que funcione al 100% de la misma manera.
+1 para "¿podemos confiar?". Básicamente es necesario volver a probar toda la aplicación. –
No, en realidad no lo hace. Lo que debe hacer es probar la herramienta de conversión para asegurarse de que traduce correctamente todas y cada una de las construcciones y composiciones. Así es como la gente prueba los compiladores. Si no pudiera hacer esto, no podría confiar en que su compilador genere código de máquina que coincida con su código C++. Es cierto, no puedes hacerlo a la perfección. Pero puedes hacerlo bastante bien. Los compiladores son una tecnología extremadamente confiable para la traducción. No se puede escatimar en las pruebas del compilador, de acuerdo. –
Creo que algunas organizaciones podrían encontrar útil, en particular las organizaciones dónde la interconexión con/el diseño alrededor de código heredado se ha vuelto más costoso y problemático que convertir el código de Java (u otro idioma)
while ((CostToPortToJava > CostOfNotPortingOverTime++) && DoesLegacyCodeStillWork())
{
StayWithLegacyCode();
}
PortCodeToJava();
Probablemente un poco de ambos. Hay empresas que proporcionan herramientas y servicios para la conversión utilizando técnicas automáticas y manuales.
Muchas compañías, sin embargo, siguen la filosofía de "no está roto", que es tan sabio como cualquier otra cosa. Especialmente dado que muchas conversiones resultan en intentos de "mejorar" el sistema existente o tratar de introducir filosofías modernas de diseño/construcción de software y resultan en un desastre.
Muchos sistemas escritos en Cobol tienen muchas transacciones pasando por ellos. Funcionan bien en las plataformas de mainframe en las que se ejecutan. Sería arriesgado cambiarlos solo por el bien del cambio.
Hay algunos factores aquí:
Va a llevar mucho tiempo; cada cierto tiempo, parte de uno de los programas deja de funcionar o no puede hacer algo y se reemplaza. No veo a muchos gerentes con problemas para todos los FUD en uno de estos proyectos, y los plazos son bastante largos en términos de rendimiento del dinero gastado.
Algo para saber sobre las antiguas aplicaciones COBOL, además de la diferencia de idioma, es que en muchas estructuras de datos creadas en estas aplicaciones no se ajustan a ninguna estructura posterior de RDBMS, entonces realmente estaríamos hablando de repensar una gran cantidad de la arquitectura y el diseño subyacentes, no solo cambiar la sintaxis del lenguaje, y reemplazarlo tendría mucho riesgo de desempeño una vez que tocara las cargas del mundo real, incluso si se pudiera controlar suficientemente.
La conclusión es que es más económico instalar nuevas funciones en un lenguaje moderno que reescribirlo. Mientras ese continúe siendo el caso, COBOL continuará viviendo.
Cobol tiene la ventaja de ser rápido para mover datos, que es lo que ese tipo de aplicaciones tienden a hacer MUCHO. Además, las máquinas están diseñadas para E/S, no para velocidades de procesamiento. Por lo tanto, cualquier traducción a otro idioma probablemente sea más lenta que la contraparte de Cobol en hardware idéntico o similar, sin dejar ninguna razón para hacerlo.
Déjame hacerte una pregunta contraria: ¿POR QUÉ convertirla, si tienes algo en su lugar que funcione?
(Similar a derribar un puente cada 10 años simplemente para reconstruirlo de nuevo inmediatamente después - generalmente siempre es más barato simplemente mantener lo que tiene).
¿Por qué COBOL es más rápido para mover datos que los idiomas modernos? ¿Qué es especial para que esto suceda? ¿Y por qué otros idiomas no lo hacen? – Nosredna
Por lo que he entendido, Cobol tiene construcciones para agrupar información en grumos que luego se pueden tratar como una sola unidad, incluso cuando se lee hacia/desde el disco. Esto reduce los requisitos de la CPU y permite que la máquina se construya con énfasis en E/S. Las primeras implementaciones de Java en la arquitectura middleframe de IBM fueron abismales ya que tenían muy poca potencia de CPU. –
También puede leer una estructura como monolito en C. Esa no es la razón. –
COBOL es, en efecto, un magnífico DSL (lenguaje específico del dominio).
Su dominio son las reglas de negocios como parte integrante de (principalmente) aplicaciones back-end.
Encontrar otro idioma que ....
.... y tendrá la aplicación asesina para aplicaciones empresariales de backend.
COBOL es simplemente otro lenguaje de programación. Tiene declaraciones escalares y de registro. Tiene instrucciones de asignación, si y hacer. Tiene llamadas de subrutina. (Incluso tiene características OOP si está utilizando un compilador moderno). Eso lo hace como C y Java. NO es un dominio específico más que Java. –
Existen traductores alrededor de los cuales se pueden modificar a bajo costo para que funcionen en una máquina o sistema operativo específico y algunos están disponibles desde Inglaterra y se pueden ejecutar allí o en el sitio. Existen versiones estándar para los modelos principales (cualquiera puede contactarme sobre ellos). Cobol a otro código fuente de lenguaje o script es relativamente fácil de hacer automáticamente y produciría un archivo de texto para importar a un archivo fuente en el equipo de destino con 95% o más de compatibilidad de código. Enmiendas manuales simples son todo lo que se necesita antes de ejecutar el compilador o el software JIT para lograr un nuevo programa: no se olvide de modificar el lenguaje de comando de trabajo o macro para trabajos de mainframe cuando se prueban o se inician. Existen nuevos compiladores cobol para mainframes ICT/ICL y uno o dos más y compilan más rápido que el software anterior y, a veces, el nuevo programa compilado puede ejecutarse varias veces más rápido.
De acuerdo. Hay una increíble cantidad de COBOL por ahí. Lo arreglas cuando se rompe. La evaluación de Y2K fue un gran costo. – Nosredna
Esta situación no es exclusiva de COBOL. La razón por la cual la mayoría de los sistemas de aplicaciones grandes no se convierten a su idioma favorito es que el costo y el riesgo de hacerlo son muy altos, y si la aplicación es crítica para la misión, entonces una empresa arriesgada es simplemente estúpida. Ahora, uno puede * automatizar * la conversión de COBOL a Java. Entonces no importa si sabes lo que hace, siempre y cuando el código convertido haga lo mismo. Los gerentes aún tienen miedo de esto, porque es difícil saber si el traductor es confiable. –
@Ira Baxter: Tiene un código heredado que no puede especificar por completo y considera que es un riesgo realizar cualquier tipo de cambio. Esa es la definición de trabajo de un pasivo. Mantenerlo porque es * arriesgado * reemplazarlo es simplemente una locura. Está manteniendo una antigüedad costosa simplemente porque es una antigüedad costosa. Si cree que es riesgoso reemplazarlo, entonces * debe * reemplazarlo con algo que tenga una especificación conocida y que elimine todos los riesgos. –