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

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.