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

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

GnuCOBOL, दो दशकों की मेहनत से बना एक open source COBOL compiler, अब औद्योगिक उपयोग के लिए पर्याप्त परिपक्व माना जा रहा है, जिससे legacy COBOL systems को महंगे mainframes से हटाने की संभावनाओं पर फिर ध्यान गया है। टिप्पणीकार बताते हैं कि migration की वास्तविक बाधाएँ केवल COBOL भाषा नहीं हैं, बल्कि उसका पूरा ecosystem है—JCL, transaction monitors, hierarchical databases, और domain-specific financial math, जिन्हें faithfully reimplement करना कठिन है। कई लोगों का तर्क है कि क्योंकि ये systems स्थिर, business-critical हैं और दशकों के खराब तरीके से documented rules को समेटे हुए हैं, इसलिए संगठनों के लिए COBOL को बनाए रखना और धीरे-धीरे बढ़ाना, उसे modern languages में rewrite करने से अक्सर सस्ता और कम जोखिमभरा होता है।

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 के रूप में ही देखते हैं।