20 Years in the Making, GnuCOBOL Is Ready for Industry

Original Article ↗ Hacker News Discussion ↗

GnuCOBOL’s Maturity and Standards Compliance

  • Seen as “ready” largely because of stability and high COBOL‑85 conformance (~97% of tests passed).
  • Commenters note that even many proprietary COBOLs never reach full standard compliance.
  • Uses GNU MP for arithmetic to match traditional COBOL fixed‑precision behavior rather than IEEE‑754 floats.
  • Lacks newer COBOL features like objects and messaging from recent standards (e.g., COBOL 2022/2023).

COBOL’s Role in Current Systems

  • Most production COBOL is on IBM mainframes, tightly coupled with JCL, databases (DB2, IMS, DMS), and transaction monitors (CICS, ACMS).
  • Also common on non‑IBM platforms: OpenVMS, OS2200, various Unix flavors, and x86/Linux with vendors like Micro Focus.
  • Used heavily in finance, payroll, billing, ERP, and other “boring but critical” back‑office workloads.

Mainframes vs Cloud and Reliability

  • Mainframes described as engineered for “five nines” availability, with extreme redundancy and very rare downtime.
  • Outages experienced by banks are often blamed on surrounding server infrastructure, not the mainframe core.
  • Cloud “five nines” is criticized as mostly a billing/credit SLA, not true nonstop operation.
  • Some report mainframe environments that are actually brittle in practice, so reliability claims are not universal.

Migration, Ecosystem, and JCL

  • GnuCOBOL is seen as only half a migration story: you still need JCL, CICS‑like transaction monitoring, and mainframe‑style databases.
  • JCL is considered essential for batch; REXX is often used to generate JCL rather than replace it.
  • Many migration attempts (including COBOL‑to‑C transliteration) are described as painful or resulting in hard‑to‑maintain systems.
  • Failed or endlessly repeated modern rewrites of COBOL systems are cited as a common pattern.

Numerical Correctness and “Money Math”

  • COBOL’s decimal arithmetic and fixed precision are key for financial systems.
  • Porting to languages that default to binary floating point is risky; correct equivalents (BigDecimal, etc.) exist but are not idiomatic and can be slow.
  • This mathematical behavior is a major reason organizations hesitate to move off COBOL.

Language Characteristics and Developer Experience

  • COBOL is verbose and data‑definition‑oriented, but many find it straightforward for its intended domain.
  • Strong static data layouts (PICTURE clauses) avoid buffer overflows and memory corruption; memory is explicitly defined, not dynamically allocated.
  • Hard parts are less about syntax and more about domain complexity and mainframe tooling.
  • There is ongoing, albeit niche, new COBOL development, often as part of larger ERP or legacy platforms.

Why Legacy COBOL Persists

  • Core accounting, payroll, and financial rules change slowly; existing systems embody decades of legislation, union agreements, and edge cases.
  • Often no complete set of current requirements exists outside the running code itself; the system is effectively the specification.
  • Incremental changes in COBOL are cheaper and less risky than full rewrites, especially when nobody fully understands all the business logic.
  • Many “old” systems are ships of Theseus: heavily modified over time but never fundamentally replaced.

Adoption Prospects and Skepticism

  • Enthusiasm for GnuCOBOL as a free, standards‑oriented compiler and potential migration tool.
  • Skepticism that large mainframe shops will switch due to regulatory constraints, ecosystem lock‑in, and risk aversion.
  • Some doubt whether many greenfield projects would ever choose COBOL today; most expect it to remain a maintenance and incremental‑change language.