विरासत सॉफ़्टवेयर के अलावा, COBOL का उपयोग करने के क्या कारण हैं?


11

COBOL अभी भी (भारी?) वित्तीय कंप्यूटिंग के लिए उपयोग किया जाता है। यह एक पुरानी भाषा है, और AFAIK अधिकांश प्रोग्रामर नफरत करते हैं, या कम से कम नापसंद करते हैं, COBOL। यह एक प्रश्न लाता है: एकमात्र कारण है COBOL अभी भी उपयोग किया जाता है कि विरासत सॉफ़्टवेयर इसका उपयोग करता है, या क्या इसकी प्रोग्रामिंग भाषाओं पर कोई वास्तविक लाभ है?

बस उत्सुक।


3
पुराना अपने आप में एक कारण नहीं है।

नहीं, लेकिन इसकी वजह से आधुनिक सुविधाओं की कमी है। यह इतना महत्वपूर्ण नहीं है, हालांकि अगर भाषा अन्यथा अच्छी तरह से डिज़ाइन की गई है।
Anto

अभी भी केवल बैंकिंग में ही नहीं, बल्कि सरकार में भी इसका भारी उपयोग किया जाता है।
BBlake

6
"अधिकांश प्रोग्रामर COBOL से नफरत करते हैं" - ठीक है, मुझे पूरा यकीन है कि अधिकांश प्रोग्रामर ने कभी भी इसका उपयोग नहीं किया है। मुझे आश्चर्य होगा अगर इन "हेटर्स" के 5% से अधिक लोगों को इसके सिंटैक्स या फॉर्म पर कोई विचार था। वे बस इसे विरासत प्रणालियों की बुराई के उदाहरण के रूप में उपयोग करते हैं, वास्तव में यह जाने बिना कि क्या हो रहा है। इसी तरह से फोरट्रान को अक्सर माना जाता है।
TZHX

@TZHX: पूरे उद्धरण में "AFAIK सबसे अधिक प्रोग्रामर नफरत, या कम से कम नापसंद, COBOL" होना चाहिए। मैं यह नहीं कह रहा हूं कि यह ऐसा है, यह सिर्फ मैंने कैसे स्थिति की व्याख्या की है। लेकिन आप जो कहते हैं वह सच हो सकता है, लेकिन मुझे खुद कुछ भी कहने के लिए यह अच्छी तरह से नहीं पता है, मैंने जो कुछ भी इस्तेमाल किया वह सभी लोगों की राय पर व्यक्तिगत टिप्पणियों का था (जो आपके द्वारा कहे गए कार्यों से बिल्कुल प्रभावित हो सकता है)।
एंटो

जवाबों:


12

यह अब ज्यादातर विरासत है। कई महत्वपूर्ण व्यवसाय प्रणालियां अभी भी केवल इस तथ्य के लिए COBOL में हैं कि वे इतनी बड़ी और एकीकृत हैं कि पुनर्लेखन की लागत इसके लायक नहीं लगती है। कोबोल में एक नई प्रणाली लिखना संभवत: अब संभव नहीं है, क्योंकि अधिकांश कोबोल डेवलपर्स इतने दुर्लभ हैं कि वे विशेष कौशल (अब एक फॉक्सप्रो डेवलपर के समान) के लिए काफी राशि में खींच सकते हैं। COBOL ऐप को इधर-उधर रखने के कुछ कारण नहीं हैं, लेकिन दुर्भाग्य से आम तर्क यह है कि COBOL ऐप पहले से ही इन-प्लेस, विश्वसनीय और अन्य सिस्टम के साथ युग्मित है जहाँ इसे बदलना असंभव है। यह तर्क बिल्कुल वैसा ही है क्योंकि इसे ऐसी स्थिति में आने से पहले ही बदल दिया जाना चाहिए, जहां ऐप चलाने वाले एकमात्र हार्डवेयर को Ebay भागों से 80/90 के दशक में कस्टम बनाया जाना है।


आप क्या कहते हैं "यह अब ज्यादातर विरासत है"? मुझे नहीं लगता कि आप वास्तव में जानते हैं कि आप किस बारे में बात कर रहे हैं। मैं अभी कई मिलियन डॉलर के नए COBOL प्रोजेक्ट पर काम कर रहा हूं। मुझे कई अन्य बहुत बड़ी नई विकास परियोजनाओं का भी पता है, जो COBOL को उनकी मुख्य कार्यान्वयन भाषा के रूप में उपयोग करते हैं। अपने हिस्से पर इच्छाधारी सोच इसे वास्तविकता नहीं बनाती है।
नीलबेल १B

1
मुझसे मत लो। ओ'रिले के शोध का कहना है कि कोबोल की किताब की बिक्री हर दूसरी भाषा की तुलना में किसी भी निकट नहीं है। ऐसा इसलिए है क्योंकि डेवलपर्स में रुचि की कमी है, या इसका उपयोग करने वाले पर्याप्त डेवलपर्स नहीं हैं। मुझे यकीन है कि आप COBOL का उपयोग करके नया विकास पा सकते हैं, लेकिन यह अभी भी पूरी तरह से विरासत (सभी विरासत नहीं) है। मुझे यकीन है कि आप जैसे कोई व्यक्ति जो स्वयं COBOL में माहिर हैं, उनके अन्य लोगों से संबंध होंगे जो केवल COBOL का उपयोग करते हैं। जैसे यह मेरे साथ होगा, केवल एक भाषा का उपयोग करने वाले दोस्तों का मतलब यह नहीं है कि मैं अल्पसंख्यक नहीं हूं।
रयान हेस

हमारी कंपनी में हम मौजूदा कोड को बहुत कॉपी / पेस्ट करते हैं, इसे हमारी आवश्यकताओं के अनुरूप बनाते हैं, और कहते हैं "किया"। सौभाग्य से मुझे अपना विकास C # / VB
वेन वर्नर

4

COBOL अभी भी (भारी?) वित्तीय कंप्यूटिंग के लिए उपयोग किया जाता है।

क्या यह?

यह उस पर निर्भर करता है जिसे आप वित्तीय कंप्यूटिंग कहते हैं। यदि आप वित्तीय संस्थानों द्वारा संचालित सभी कोड को हां कहते हैं, तो यह संभवतः है। अधिकांश में 60 और 70 के दशक में व्यावसायिक नियम लिखे गए हैं। एक नए वातावरण में इस तरह के उन्नयन प्रणालियों का जोखिम + लागत इसके लायक नहीं है। मुझे संदेह है कि वहाँ कोई है जो नए COBOL कोड लिख रहा है। आज उदाहरण के लिए .NET स्टैक में एकीकृत COBOL कंपाइलर हैं। अक्सर आधुनिक सॉफ़्टवेयर स्टैक में विरासत अनुप्रयोगों को एकीकृत करने और लाभ उठाने के लिए उपकरण होते हैं, लेकिन वे उपकरण अक्सर उन लोगों के लिए अज्ञात होते हैं जिन्हें उनका उपयोग नहीं करना पड़ता है, क्योंकि यह एक बहुत ही आला बाजार है।

अब अगर आप वित्तीय कंप्यूटिंग को कुछ और अधिक कहते हैं जैसे कि क्वांटिटेटिव फाइनेंस के लिए सॉफ्टवेयर मैंने कॉबल का उपयोग करने वाले किसी व्यक्ति के बारे में कभी नहीं सुना है। C ++ कुछ आम भाषाओं जैसे k, एक APL व्युत्पन्न के साथ अधिक सामान्य है।


kऔर यह qइस तरह के दर्द हैं
एंड्री

@ और यह स्वाद का मामला है। मुझे मजा आता है।
विटोर पाय

आप भाग्यशाली हैं। मेरे लिए सबसे बड़ी समस्या सामान्य आईडीई और बेकार त्रुटि संदेशों की कमी है
एंड्री

2
@Andrey, आला भाषाओं का उपयोग करते समय मुख्यधारा के विकास के माहौल से दूर जाना सबसे बड़ी समस्या है। मैंने टेम्प्लेट हैवी C ++ कोड का इस्तेमाल करने से पहले किया था ताकि मैं कुछ हद तक बेकार के मैसेज का इस्तेमाल करूँ :)
Vitor Py

@Andrey, IBM के पास कोबोल के लिए ग्रहण आधारित टूलिंग है।

4

कोबोल ज्यादातर विरासत का उपयोग अब देखती है। यह उपयोगकर्ता का आधार धीरे-धीरे घटते-घटते है, क्योंकि कोई नया एप्लिकेशन नहीं लिखा जा रहा है और पुराने धीरे-धीरे लिखे जा रहे हैं, लेकिन निश्चित रूप से, चरणबद्ध हैं।

अधिकांश कोबोल सिस्टम जो जल्दी और सस्ते में बदल सकते थे, उन्हें पहले ही बदल दिया गया है। जो नहीं हैं, वे मरम्मत या बदलने के लिए अधिक से अधिक महंगे हो जाते हैं, लेकिन नई प्रणालियों के सापेक्ष बनाए रखने के लिए सस्ता और सस्ता है - वे सस्ते, आउट-डेटेड हार्डवेयर पर अच्छी तरह से चलते हैं, और, कई वर्षों की सेवा के बाद, नहीं हैं अब कोई नया बग दिखा रहा है। अधिकांश बग या तो तय हो गए हैं, या लंबे समय से चली आ रही परंपराएं हैं जो काम के आसपास फिट बैठती हैं। आमतौर पर रखरखाव एक या दो विशेष कर्मचारियों के लिए कम कर दिया गया है, जो लंबे समय तक सिस्टम पर काम करने के बाद जानते हैं कि आप जितना कल्पना कर सकते हैं, उससे अधिक तीव्रता से इसे जानते हैं।

तकनीकी दृष्टिकोण से भी, पुराने सिस्टम को बनाए रखने के लिए आमतौर पर कुछ ध्वनि कारण होते हैं। वे अपेक्षाकृत स्थिर हैं, ज्यादातर बग-फिक्स्ड हैं, और अंत-उपयोगकर्ता द्वारा अच्छी तरह से ज्ञात / समझा जाता है।

आप देखेंगे कि सिस्टम को अंततः बदला जा रहा है, हालाँकि। आमतौर पर यह कदम व्यापारिक पक्ष से आता है:

  • वर्तमान प्रणाली के उपयोगकर्ताओं को युवा उपयोगकर्ताओं द्वारा प्रतिस्थापित किया जाता है, जिन्हें पुरातन इंटरफ़ेस का उपयोग करने का तरीका जानने के लिए आश्वस्त नहीं किया जा सकता है
  • कंपनी को किसी भी कर्मचारी के वेतन की तुलना में अपमानजनक नहीं है, इस प्रणाली को बनाए रखने के लिए किराया नहीं मिल सकता है
  • एक बड़े बजट के साथ कोई व्यक्ति यह पता लगाने के लिए शर्मिंदा हो जाता है कि कंपनी का एक मुख्य सिस्टम हार्डवेयर पर चल रहा है जिसे लैपटॉप पर वीएम द्वारा प्रतिस्थापित किया जा सकता है
  • एक नया, कमोडिटी सिस्टम, साथ आता है, जिसका उपयोग शुरू करना वास्तव में सस्ता है
  • पुरानी प्रणालियों का उपयोग करने वाली कंपनी का अधिग्रहण किया जाता है, दिवालिया हो जाता है या अन्यथा वास्तव में मौजूदा बंद हो जाता है
  • नए, तत्काल आवश्यक कार्यक्षमता का एक महत्वपूर्ण सा, विरासत प्रणाली के साथ बातचीत करने के लिए सस्ते में नहीं बनाया जा सकता है

2
इतना निश्चित होने के लिए आपकी पृष्ठभूमि क्या है?

मैं सशक्त रूप से बता सकता हूं कि आपकी निश्चितता गलत है - हमारे पास कई छोटे (20-30) नए कोबर हैं जो नए कोबोल कोड लिख रहे हैं (मौजूदा सिस्टम को अपडेट और / या कॉपी कर रहे हैं), और हमारे पास हमारे 200 डेवलपर्स में से कम से कम 10% हैं जो कोबोल में अपने विकास के समय का 80% + खर्च करते हैं। मुझे लगता है कि आप पाएंगे कि कोबोल का उपयोग करने वाले अधिकांश स्थान आपके द्वारा वर्णित विवरण के बिल्कुल विपरीत हैं।
वेन वर्नर

4

आश्चर्य है कि आप "अधिकांश प्रोग्रामर" से क्या मतलब है। मैं कोबोल प्रोग्रामर, जावा प्रोग्रामर, .NET प्रोग्रामर (एकवचन में), पुरानी शैली VB प्रोग्रामर के रूप में एक ही मंजिल पर एक बड़ी आईटी शॉप में काम करता हूं। कोई नफ़रत या नापसंदगी नहीं है। कोबोल किसी भी अन्य प्रोग्रामिंग भाषा की तरह एक भाषा है- कोबोल में प्रोग्रामिंग करने वाले लोग ऐसा करते हैं क्योंकि यह उनके लिए एक काम है जो जावा में प्रोग्रामिंग करने या ट्रक चलाने से अलग नहीं है। अमेरिका में लोकप्रिय गर्भाधान के विपरीत बहुत अधिक कोबोल लिखा जाना जारी है, केवल इसका अधिकांश हिस्सा भारत में है जहां हर दिन नए कोबोल प्रोग्रामर काम करना शुरू करते हैं।

मुझे लगता है कि यही वजह है कि कोबोल में बहुत सारी नेट नई प्रणालियां नहीं लिखी गई हैं क्योंकि कोबोल के लिए जिस तरह की प्रणालियां (बड़ी मात्रा में फाइल प्रोसेसिंग) अनुकूल हैं, वे सभी पहले से ही लिखी गई हैं। बहुत कम नए बड़े निगम इन दिनों बनते हैं। और जो लोग पेरोल और कोबोल सिस्टम चलाने वाली कंपनियों को पेरोल और लाभ जैसी चीजों की आउटसोर्सिंग कर रहे हैं।


2

PeopleSoft में कोर कोड का एक बड़ा हिस्सा COBOL में लिखा गया है।


मुझे समझने के लिए दिया गया है कि 2004 में एक आईटी सम्मेलन में PeopleSoft प्रतिनिधि के साथ बात करने से पहले, Oracle ने उन्हें अधिग्रहित कर लिया, उस समय यह केवल उस उत्पाद का एक मॉड्यूल था जो अभी भी COBOL में था।
केनाह

यह वैसे भी अन्य भाषाओं पर COBOL को एक लाभ कैसे देता है?
मैथ्यू

2

COBOL के 20 वर्षों के अनुभव के साथ, तीन अलग-अलग मेनफ्रेम पर, यह मेरी विनम्र राय है कि कुछ सच्चे COBOL प्रोग्रामर हैं और इसके बजाय IBM प्रोग्रामर, Sperry (Unisys 2200) प्रोग्रामर, Burroughs (Unysys MCP) प्रोग्रामर, और Tandem (HP NonStop) हैं। प्रोग्रामर। उनके सम्मान में, मुझे HP 3000 प्रोग्रामर, BULL प्रोग्रामर और DEC प्रोग्रामर की उपस्थिति का भी उल्लेख करना चाहिए।

COBOL अधिकांश भाग के लिए लोहे के बड़े बक्सों पर चलता है। शायद मेरे ही मानकों से, केवल सही COBOL प्रोग्रामर हैं, जो UNIX बॉक्स पर COBOL लिख रहे हैं। वाह, मैं इस बारे में सुनने जा रहा हूं।

क्योंकि हार्डवेयर केंद्रीय टुकड़ा है, अधिकांश प्रोग्रामर जो COBOL लिखते हैं, वे उस हार्डवेयर द्वारा स्वयं की पहचान करते हैं जिस पर वे लिखते हैं। वर्षों से, अन्य प्रोग्रामर को सुनने से मुझे स्पेरी, बर्रोज़ या टेंडेम की खूबियों के बारे में पता चलता है, मैंने अक्सर सोचा है कि अगर मैं उन्हें गोल कर दूं और उन्हें एक कमरे में रख दूं तो वे किस तरह एक जगह छोड़ेंगे जब तक वे छोड़ने में असमर्थ हो जाएं। सभी COBOL के लिए एक हार्डवेयर प्लेटफॉर्म पर सहमति। मैंने अन्य प्लेटफार्मों का उल्लेख नहीं किया क्योंकि मैंने उन पर कभी काम नहीं किया।

मैंने कई आईबीएम प्रोग्रामरों के साथ मुलाकात और बातचीत की है, और वे खुद को कॉबोल प्रोग्रामर के रूप में संदर्भित करेंगे। हालांकि, अगर कोई उन्हें बातचीत में संलग्न करता है, तो वे जल्दी से आईबीएम विशिष्ट प्रक्रियाओं और उपकरणों का उल्लेख करना शुरू करते हैं। COBOL की हार्डवेयर-केंद्रित प्रकृति को देखते हुए, यह सभी हार्डवेयर प्लेटफ़ॉर्म के लिए बहुत समझ में आता है।

क्योंकि COBOL आमतौर पर हार्डवेयर के एक बहुत महंगे टुकड़े से बंधा होता है, जब तक कि उस हार्डवेयर का टुकड़ा उस पर संकलित COBOL प्रोग्राम चलाता है, तब माइग्रेशन के लिए COBOL से माइग्रेट करने की तीव्र इच्छा नहीं होती है। हालांकि, COBOL प्रोग्रामर्स की बढ़ती उम्र के साथ, प्रवास अपरिहार्य है।

चूँकि COBOL चलाने वाले सभी बड़े लोहे के बक्से जावा को भी चलाएंगे, Java COBOL से दूर जाने का प्राकृतिक मार्ग है। कोड को परिवर्तित किया जा सकता है, विशेषकर अब डाउन इकोनॉमी में, बल्कि किफायती मूल्य के लिए। एक बार जब कोई कॉबोल नहीं है, केवल जावा, हार्डवेयर के उस बड़े महंगे टुकड़े पर, तो संगठन में उच्चतर कोई व्यक्ति यह सोचकर शुरू करने जा रहा है कि क्या जावा कोड को हार्डवेयर के कुछ अन्य कम खर्चीले टुकड़े पर ले जाना संभव है।

IBM, Sperry, Burroughs, और Tandem प्रोग्रामर को यह पता है, इसलिए वे इस विचार को प्रस्तुत करने की संभावना नहीं रखेंगे। यह कुछ के लिए एक बलिदान होगा।


+1, वास्तव में बहुत महंगा है। प्लस ने इंगित किया कि जावा न्यू कोबोल बन रहा है - जिसे मैंने खुद देखा है और मैं सिर्फ एक युवा हिरन हूं, इसलिए किसी को अनुभव के साथ देखना दिलचस्प है।
वेन वर्नर
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.