Después de 20 años de desarrollo, GnuCOBOL está listo para la industria

Artículo original ↗ Discusión en Hacker News ↗

GnuCOBOL, un compilador de COBOL de código abierto desarrollado durante dos décadas, ya se considera lo bastante maduro para uso industrial, lo que ha renovado la atención sobre cómo los sistemas COBOL heredados podrían salir de los costosos mainframes. Los comentaristas destacan que los verdaderos obstáculos para la migración no son solo el lenguaje COBOL, sino todo su ecosistema: JCL, monitores de transacciones, bases de datos jerárquicas y una aritmética financiera específica de dominio que es difícil de reimplementar fielmente. Muchos sostienen que, como estos sistemas son estables, críticos para el negocio y codifican décadas de reglas mal documentadas, a las organizaciones a menudo les resulta más barato y menos arriesgado mantener COBOL y ampliarlo de forma incremental que reescribirlo en lenguajes modernos.

Madurez de GnuCOBOL y cumplimiento de estándares

  • Se considera “listo” en gran parte por su estabilidad y su alto cumplimiento de COBOL‑85 (se aprobaron ~97% de las pruebas).
  • Los comentaristas señalan que incluso muchos COBOL propietarios nunca alcanzan el cumplimiento total del estándar.
  • Usa GNU MP para la aritmética, a fin de igualar el comportamiento tradicional de precisión fija de COBOL en lugar de flotantes IEEE‑754.
  • Le faltan funciones más recientes de COBOL, como objetos y mensajería, de estándares recientes (p. ej., COBOL 2022/2023).

El papel de COBOL en los sistemas actuales

  • La mayor parte de COBOL en producción está en mainframes de IBM, fuertemente acoplado con JCL, bases de datos (DB2, IMS, DMS) y monitores de transacciones (CICS, ACMS).
  • También es común en plataformas no IBM: OpenVMS, OS2200, distintas variantes de Unix y x86/Linux con proveedores como Micro Focus.
  • Se usa mucho en finanzas, nóminas, facturación, ERP y otras cargas de trabajo de back office “aburridas pero críticas”.

Mainframes frente a la nube y la fiabilidad

  • Los mainframes se describen como diseñados para disponibilidad de “cinco nueves”, con redundancia extrema y tiempos de inactividad muy raros.
  • Las caídas que sufren los bancos a menudo se atribuyen a la infraestructura de servidores circundante, no al núcleo del mainframe.
  • Se critica que los “cinco nueves” de la nube son sobre todo un SLA de facturación/créditos, no una operación realmente ininterrumpida.
  • Algunos informan de entornos de mainframe que, en la práctica, sí son frágiles, por lo que las afirmaciones de fiabilidad no son universales.

Migración, ecosistema y JCL

  • GnuCOBOL se ve solo como la mitad de una historia de migración: todavía necesitas JCL, monitorización de transacciones al estilo CICS y bases de datos al estilo mainframe.
  • JCL se considera esencial para batch; REXX se usa a menudo para generar JCL en lugar de reemplazarlo.
  • Muchos intentos de migración (incluida la transliteración de COBOL a C) se describen como dolorosos o como sistemas resultantes difíciles de mantener.
  • Se citan como patrón común las reescrituras modernas fallidas o repetidas sin fin de sistemas COBOL.

Corrección numérica y “aritmética del dinero”

  • La aritmética decimal y la precisión fija de COBOL son clave para los sistemas financieros.
  • Portar a lenguajes que por defecto usan coma flotante binaria es arriesgado; existen equivalentes correctos (BigDecimal, etc.), pero no son idiomáticos y pueden ser lentos.
  • Este comportamiento matemático es una de las principales razones por las que las organizaciones dudan en abandonar COBOL.

Características del lenguaje y experiencia del desarrollador

  • COBOL es verboso y orientado a la definición de datos, pero muchos lo consideran sencillo para su dominio previsto.
  • Los diseños estáticos de datos fuertes (cláusulas PICTURE) evitan desbordamientos de búfer y corrupción de memoria; la memoria se define explícitamente, no se asigna dinámicamente.
  • Las partes difíciles tienen menos que ver con la sintaxis y más con la complejidad del dominio y las herramientas de mainframe.
  • Sigue existiendo desarrollo nuevo en COBOL, aunque de nicho, a menudo como parte de plataformas ERP o heredadas más grandes.

Por qué persiste COBOL heredado

  • Las reglas centrales de contabilidad, nóminas y finanzas cambian lentamente; los sistemas existentes encarnan décadas de legislación, acuerdos sindicales y casos extremos.
  • A menudo no existe un conjunto completo de requisitos actuales fuera del propio código en ejecución; el sistema es, en efecto, la especificación.
  • Los cambios incrementales en COBOL son más baratos y menos arriesgados que las reescrituras completas, especialmente cuando nadie entiende del todo toda la lógica de negocio.
  • Muchos sistemas “viejos” son naves de Teseo: muy modificados con el tiempo, pero nunca sustituidos fundamentalmente.

Perspectivas de adopción y escepticismo

  • Entusiasmo por GnuCOBOL como compilador gratuito y orientado a estándares, y como posible herramienta de migración.
  • Escepticismo de que las grandes instalaciones de mainframe vayan a cambiar por restricciones regulatorias, dependencia del ecosistema y aversión al riesgo.
  • Algunos dudan de que muchos proyectos greenfield eligieran COBOL hoy; la mayoría espera que siga siendo un lenguaje de mantenimiento y cambio incremental.