20 वर्षों की मेहनत के बाद, GnuCOBOL उद्योग के लिए तैयार है

मूल लेख ↗ Hacker News चर्चा ↗

GnuCOBOL की परिपक्वता और मानक अनुपालन

  • इसे काफी हद तक इसकी स्थिरता और COBOL‑85 के उच्च अनुपालन (~97% परीक्षण पास) के कारण “तैयार” माना जा रहा है।
  • टिप्पणीकारों का कहना है कि कई proprietary COBOL भी कभी पूर्ण मानक अनुपालन तक नहीं पहुँचते।
  • पारंपरिक COBOL के fixed-precision व्यवहार से मेल खाने के लिए गणना में GNU MP का उपयोग करता है, IEEE‑754 floats के बजाय।
  • हाल के मानकों (जैसे COBOL 2022/2023) में मौजूद objects और messaging जैसी नई COBOL सुविधाएँ इसमें नहीं हैं।

वर्तमान प्रणालियों में COBOL की भूमिका

  • अधिकांश production COBOL IBM mainframes पर है, जहाँ यह JCL, डेटाबेस (DB2, IMS, DMS), और transaction monitors (CICS, ACMS) के साथ गहराई से जुड़ा है।
  • गैर‑IBM प्लेटफ़ॉर्म पर भी यह सामान्य है: OpenVMS, OS2200, विभिन्न Unix flavors, और x86/Linux पर Micro Focus जैसे vendors के साथ।
  • इसका व्यापक उपयोग finance, payroll, billing, ERP, और अन्य “boring but critical” back-office workloads में होता है।

Mainframes बनाम Cloud और विश्वसनीयता

  • Mainframes को “five nines” availability के लिए engineered बताया जाता है, जिसमें अत्यधिक redundancy और बहुत कम downtime होता है।
  • बैंकों द्वारा अनुभव किए गए outages अक्सर आसपास की server infrastructure पर दोष मढ़े जाते हैं, न कि mainframe core पर।
  • Cloud “five nines” की आलोचना मुख्यतः billing/credit SLA के रूप में की जाती है, न कि वास्तविक nonstop operation के रूप में।
  • कुछ लोग ऐसे mainframe environments की भी रिपोर्ट करते हैं जो व्यवहार में brittle हैं, इसलिए reliability के दावे सार्वभौमिक नहीं हैं।

Migration, Ecosystem, और JCL

  • GnuCOBOL को migration की कहानी का केवल आधा हिस्सा माना जाता है: आपको फिर भी JCL, CICS-जैसा transaction monitoring, और mainframe-शैली के databases की ज़रूरत होती है।
  • JCL को batch के लिए अनिवार्य माना जाता है; REXX का उपयोग अक्सर JCL generate करने के लिए किया जाता है, उसे बदलने के लिए नहीं।
  • कई migration प्रयास (COBOL-to-C transliteration सहित) को दर्दनाक या कठिन-रखरखाव वाले systems में बदलने वाला बताया गया है।
  • COBOL systems के असफल या बार-बार दोहराए गए modern rewrites को एक सामान्य पैटर्न के रूप में उद्धृत किया गया है।

Numerical Correctness और “Money Math”

  • वित्तीय प्रणालियों के लिए COBOL की decimal arithmetic और fixed precision महत्वपूर्ण हैं।
  • binary floating point को default मानने वाली languages में port करना जोखिमभरा है; सही विकल्प (BigDecimal, आदि) मौजूद हैं, लेकिन वे idiomatic नहीं हैं और धीमे हो सकते हैं।
  • यह गणितीय व्यवहार संगठनों के COBOL से हटने में हिचकिचाने का एक प्रमुख कारण है।

Language Characteristics और Developer Experience

  • COBOL verbose और data-definition-oriented है, लेकिन बहुतों को यह अपने intended domain के लिए सीधा-सादा लगता है।
  • मजबूत static data layouts (PICTURE clauses) buffer overflows और memory corruption से बचाते हैं; memory स्पष्ट रूप से परिभाषित होती है, dynamically allocate नहीं की जाती।
  • कठिनाइयाँ syntax से कम और domain complexity तथा mainframe tooling से अधिक जुड़ी होती हैं।
  • niche होने के बावजूद नई COBOL development जारी है, अक्सर बड़े ERP या legacy platforms के हिस्से के रूप में।

Legacy COBOL क्यों बना रहता है

  • core accounting, payroll, और financial rules धीरे-धीरे बदलते हैं; मौजूदा systems दशकों के legislation, union agreements, और edge cases को समेटे हुए हैं।
  • अक्सर running code के बाहर आवश्यकताओं का पूर्ण current set मौजूद नहीं होता; system ही effectively specification होता है।
  • COBOL में incremental changes full rewrites से सस्ते और कम जोखिम वाले होते हैं, खासकर जब किसी को सभी business logic पूरी तरह समझ नहीं आती।
  • कई “old” systems ship of Theseus की तरह हैं: समय के साथ भारी रूप से modified, लेकिन मूल रूप से कभी replaced नहीं हुए।

Adoption Prospects और Skepticism

  • एक free, standards-oriented compiler और संभावित migration tool के रूप में GnuCOBOL के लिए उत्साह है।
  • संदेह यह है कि बड़े mainframe shops regulatory constraints, ecosystem lock-in, और risk aversion के कारण switching करेंगे भी या नहीं।
  • कुछ लोगों को शक है कि आज कितने greenfield projects COBOL चुनेंगे; अधिकांश इसे maintenance और incremental-change language के रूप में ही देखते हैं।