20 Years in the Making, GnuCOBOL Is Ready for Industry

Original Article ↗ Hacker News Discussion ↗

GnuCOBOL, an open source COBOL compiler two decades in the making, is now considered mature enough for industrial use, prompting renewed attention to how legacy COBOL systems might move off expensive mainframes. Commenters highlight that the real obstacles to migration aren’t just the COBOL language but its surrounding ecosystem—JCL, transaction monitors, hierarchical databases, and domain-specific financial math that’s hard to faithfully reimplement. Many argue that because these systems are stable, business‑critical, and encode decades of poorly documented rules, organizations often find it cheaper and less risky to maintain and incrementally extend COBOL rather than rewrite it in modern languages.

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.