आईबीएम मेनफ्रेम पर COBOL के लिए सबसे महत्वपूर्ण सहायक सॉफ्टवेयर क्या था?
पिछली आधी सदी में, कंप्यूटर उद्योग के सबसे बड़े रुझानों में से एक माइक्रो कंप्यूटर द्वारा मेनफ्रेम का प्रतिस्थापन किया गया है। किसी भी तरह से कुल नहीं - ऑपरेशन में अभी भी कई मेनफ्रेम हैं - लेकिन उनका दिन बहुत लंबा है। यही बात COBOL के बारे में भी है, जो अभी भी कुछ क्षमता या अन्य में दुनिया के सकल घरेलू उत्पाद का एक अच्छा हिस्सा संभालती है, लेकिन निश्चित रूप से जावा की तरह COBOL बनाम अन्य भाषाओं में लिखे गए वाणिज्यिक कोड का प्रतिशत अपने चरम से काफी कम हो गया है।
यह नोट करना दिलचस्प है कि क्या नहीं हुआ है। द्वारा और बड़े, COBOL कोड को मेनफ्रेम से पोर्ट नहीं किया गया है। जहां यह अभी भी चल रहा है, यह ज्यादातर मामलों में अभी भी मेनफ्रेम पर चल रहा है। जहां उन्हें माइक्रो कंप्यूटर द्वारा बदल दिया गया है, माइक्रो कंप्यूटर अन्य भाषाओं में बड़े और चल रहे कोड हैं। यह कुछ हद तक प्रतिवाद है। सिद्धांत रूप में, सॉफ़्टवेयर को परवाह नहीं है कि हार्डवेयर किस पर चल रहा है - ठीक है, कुछ सॉफ़्टवेयर करता है, अगर यह असेंबली में लिखा गया है, या अन्यथा हार्डवेयर के साथ निम्न-स्तरीय चीजें करता है, लेकिन यह COBOL में व्यावसायिक अनुप्रयोगों का वर्णन नहीं करेगा। सहज रूप से यह उचित लगता है कि एक बार दिए गए क्षमता के लिए माइक्रो कंप्यूटर की लागत कम होने पर वह सभी कोड माइक्रो कंप्यूटर में पोर्ट होने लगेगा। लेकिन ऐसा नहीं हुआ, और मैं उत्सुक हूं कि क्यों नहीं।
एक विचार यह है कि हार्डवेयर की क्षमता सभी मामलों में नहीं थी। यहां तक कि जब माइक्रो कंप्यूटर MIPS और मेगाफ्लॉप्स के लिए मेनफ्रेम को चुनौती देना शुरू करते हैं, तो वे हार्ड डिस्क सरणी में स्टोरेज क्षमता, या टर्मिनलों की संख्या जैसे कि एक साथ सेवा की जा सकती है, अन्य मेट्रिक्स पर एक उच्च अंत मेनफ्रेम से मेल नहीं खा सकते हैं। फिर भी, वहाँ ओवरलैप था। आईबीएम 9370 पर विचार करें : 1986 में शुरू की गई एक 370-वास्तुकला मिनीकंप्यूटर; यह 4-16 एमबी रैम, 64-384 टर्मिनल क्षमता के साथ उपलब्ध था; समकालीन 386 सर्वर की क्षमताओं के साथ ओवरलैप होता है; ऐसे मामले होंगे जहां मेनफ्रेम कई अनुप्रयोगों को चला रहा था, जिनमें से कम से कम कुछ अपनी क्षमता का केवल एक छोटा हिस्सा उपयोग करेंगे; और निश्चित रूप से ऐसे मामले होंगे जहां पुराने मेनफ्रेम से कोड को पोर्ट करने की इच्छा थी, इसलिए तुलना माइक्रो कंप्यूटर की बहुत बाद की पीढ़ी के साथ हो सकती है। तो कुछ मामलों में, हार्डवेयर क्षमता होगी।
क्या अन्य आवश्यकताओं? जाहिर है, लक्ष्य मंच पर एक COBOL संकलक। यह निश्चित रूप से ऐसा है जो इस तरह के माइक्रो कंप्यूटर ऑपरेटिंग सिस्टम पर उपलब्ध था जैसे CP / M, MS-DOS, OS / 2 और Windows, जैसे CIS COBOL और Micro Focus COBOL । बेशक, संकलक को पर्याप्त रूप से सुविधा-पूर्ण और पर्याप्त गुणवत्ता की आवश्यकता होगी। यह एक तुच्छ आवश्यकता नहीं हो सकती है, उदाहरण के लिए पूर्व लिंक कहता है:
सत्तर के दशक के अंत में, कंपनी माइक्रो फोकस ने 8-बिट माइक्रो कंप्यूटर के लिए कॉम्पैक्ट इंटरएक्टिव स्टैंडर्ड COBOL (CIS COBOL) बनाया। CIS COBOL ANSI COBOL मानक X3.23 (1974) पर आधारित है। 64 किलोबाइट रैम की मेमोरी बाधाओं के कारण केवल लेवल 1 और लेवल 2 के कुछ फीचर्स ही लागू होते हैं।
ठीक है, यह समझ में आता है कि सुविधाएँ 64K मशीनों पर सीमित थीं, लेकिन किसी को उम्मीद होगी कि कुछ वर्षों में प्रतिबंध हटा दिया जाएगा। तथापि,http://www.edm2.com/index.php/Microsoft_COBOL कहते हैं
यह ध्यान दिया जाना चाहिए कि न तो Microsoft 1.x और 2.x संकलक और न ही बाद में माइक्रो फोकस खट्टा संकलक सामान्य रूप से अपने दिन में भी बहुत अच्छे माने जाते थे और पुस्तकालय समर्थन और कोड गुणवत्ता बराबर के नीचे मानी जाती थी। Microsoft 1.x / 2.x श्रृंखला में कई ख़ासियतें थीं जिनका अर्थ था कि सिस्टम से COBOL कोड को पोर्ट करने के लिए काफी समय की आवश्यकता थी। सिस्टम ज्यादातर उन लोगों द्वारा खरीदे गए थे जिन्हें मिश्रित भाषा प्रोग्रामिंग करने की आवश्यकता थी, लेकिन संस्करण 1 में भी उस के लिए समर्थन पहले से ही DOS दुनिया में उनके अधिकांश प्रतियोगियों से बेहतर था। रिलीज 3 के साथ और "व्यावसायिक श्रृंखला" टूल को शामिल करने का समर्थन उत्कृष्ट था और उपकरण अन्य Microsoft "प्रो श्रृंखला" टूल के साथ भी पूरी तरह से एकीकृत होगा।
और स्पष्ट रूप से माइक्रोसॉफ्ट और आईबीएम दोनों ने उपरोक्त समस्याओं के बावजूद माइक्रो फोकस एक को लाइसेंस देने के पक्ष में अपने स्वतंत्र पीसी कोबोल कंपाइलर्स को गिरा दिया। तो, तुच्छ बिल्कुल नहीं।
फिर भी, लक्ष्य COBOL संकलक पर्याप्त थे, और क्या चाहिए? सॉफ़्टवेयर के लिए प्रति से अधिक भाषा की आवश्यकता आम है। यदि आपके पास रूबी में लिखित वेबसाइट है, तो इसकी संभावना रेल पर भी निर्भर करती है। यदि आपके पास पायथन में लिखा मशीन लर्निंग कोड है, तो यह बहुत संभव है कि यह PyTorch या Tensorflow पर भी निर्भर करता है। यदि आपके पास COBOL में लिखा गया व्यावसायिक सॉफ़्टवेयर है, तो इस पर निर्भर होने की क्या संभावना है? मुझे आईबीएम मेनफ्रेम के बारे में ज्यादा जानकारी नहीं है, लेकिन मैं उन्हें इकट्ठा करता हूं:
- नौकरी नियंत्रण भाषा, जेसीएल। मोटे तौर पर बैश के बराबर? कुछ लिनक्स सॉफ्टवेयर में बैश स्क्रिप्ट में काफी कोड होता है, जो एक अलग शेल के साथ प्लेटफॉर्म पर पोर्ट करने के लिए nontrivial प्रयास पैदा करेगा। क्या JCL के संबंध में भी यही सच है?
- आरपीजी, रिपोर्ट जनरेशन लैंग्वेज, जो 1959 तक पूरी तरह से चल रही थी। क्रिस्टल रिपोर्ट जैसी किसी चीज के बराबर, जीयूआई के बिना? एक विशिष्ट व्यावसायिक अनुप्रयोग के संभवतः पर्याप्त मात्रा में इसे लिखा जा सकता है?
- DB2, एक संबंधपरक डेटाबेस। यह वास्तव में एक समस्या होने की संभावना कम लगती है, आंशिक रूप से क्योंकि यह केवल 1983 में जारी की गई थी, और आंशिक रूप से क्योंकि अन्य संबंधपरक डेटाबेस हैं, और उनके बीच पोर्टिंग का प्रयास, जबकि nontrivial, इससे कम होगा यदि आपको पोर्ट करना था एक अलग तरह का डेटाबेस।
- IMS, एक पूर्व-संबंधपरक डेटाबेस। यह एक समस्या होने की संभावना अधिक लगती है, आंशिक रूप से क्योंकि यह 1966 में वापस आ जाती है और आंशिक रूप से क्योंकि एक रिलेशनल डेटाबेस से इसे पोर्ट करने का प्रयास इसी तरह से अधिक होगा।
- अन्य प्रमुख सॉफ्टवेयर घटक जिनके बारे में मुझे जानकारी नहीं है?
कौन से घटक या सुविधाएं विशिष्ट COBOL अनुप्रयोगों को पोर्ट करने में सबसे बड़ी बाधा थीं?
जवाब
टी एल; डॉ:
कौन से घटक या सुविधाएं विशिष्ट COBOL अनुप्रयोगों को पोर्ट करने में सबसे बड़ी बाधा थीं?
बस इतना है कि ऐसे कई एप्लिकेशन नहीं थे जिनसे (डेस्कटॉप) माइक्रोस में पोर्ट होने का कोई मतलब नहीं था। यदि सभी में, पूरे अनुप्रयोगों का डाउनवर्ड माइग्रेशन / 3x सिस्टम और अंततः AS400 की ओर था। जो अच्छी तरह से समर्थित और दर्द रहित था।
<शेख़ी>
जबकि मैं इसे सीधे इस प्रश्न में नहीं देखूंगा, जब यह मेनफ्रेम और उनके उपयोग / सॉफ्टवेयर करता है तो दो सामान्य गलतियाँ होती हैं
- मेनफ्रेम माइक्रोसे की तरह होते हैं, बस अधिक पुराने और खाने से अधिक स्थान
- मेनफ्रेम का उपयोग आज की तरह ही किया गया, बस पाठ आधारित टर्मिनलों के साथ।
नहीं, वे नहीं हैं और वे नहीं थे।
मेनफ्रेम एप्लिकेशन डाटा प्रोसेसिंग के बारे में हैं, कंप्यूटिंग के लिए नहीं। वे इंटरैक्टिव उपयोग (डेटा प्रविष्टि के बगल में) के बारे में नहीं हैं। और वे निजी डेटा स्टैक के बारे में नहीं हैं, लेकिन कंपनी के विस्तृत भंडार हैं। सभी मेनफ्रेम सॉफ़्टवेयर के 90% के लिए डेस्कटॉप मशीन पर और उसके लिए कोई उपयोग मामला नहीं है।
<उप-शेख़ी>
जो, BTW, यही कारण है कि माइक्रो / डेस्कटॉप कंप्यूटिंग और AFAICT के पूरे विचार के खिलाफ एक BIAS बनाया गया है, कोई मेनफ़्रेम निर्माताओं के बगल में प्रमुख मुद्दा माइक्रो कंप्यूटर की लहर को समय पर पकड़ रहा है, और अक्सर मिनी (यूनिक्सॉइड) व्यवसाय को बट्टा लगा रहा है। भी। प्रबंधन ने यह नहीं देखा कि पृथ्वी पर कोई भी डेस्कटॉप पर लॉजिस्टिक्स समेकन प्रणाली क्यों चलाना चाहेगा। और अन्य अनुप्रयोगों की कल्पना नहीं कर सकता। आखिरकार, उनके सचिवों के पास पहले से ही अच्छे चयनकर्ता टाइपराइटर थे, वे और अधिक क्या चाहते थे?
</ उप-शेख़ी>
माइकोस की तुलना मेनरोस से करना 40 टन (18-व्हीलर, रोड-ट्रेन, आपकी सड़कों पर जो कुछ भी राजा है) को एक परिवार सेडान के साथ तुलना करने जैसा है। सेडान का मतलब मालिक को फेरी देना है और वैकल्पिक थोड़ा सामान साथ लाना है, हर जगह पर ध्यान केंद्रित करने के साथ, लॉरी को परिवहन के लिए इसका मतलब है कि चालक को वहां पहुंचने का कोई इरादा नहीं है बल्कि ऑपरेटर आवश्यक है। यह हर जगह नहीं मिल सकता है, लेकिन यह हो जाता है, यह 100 सेडान क्या नहीं फावड़ा कर सकते हैं। सच है, धीमी लेकिन अधिक आर्थिक।
मेनफ्रेम ऐसे ही होते हैं। वे डाटा प्रोसेसिंग करते हैं, कंप्यूटिंग नहीं। वे पंच कार्ड प्रोसेसिंग के वारिस हैं। यही कारण है कि न केवल वे अभी भी चारों ओर हैं (और काफी समय तक रहेंगे), बल्कि यह भी कि संपूर्ण अनुप्रयोगों को माइक्रोस तक पोर्ट करने की कोई वास्तविक आवश्यकता नहीं है।
(और इसी तरह कि बड़े लॉरियों में अभी भी हमारे मोटरमार्ग भरे हुए हैं, अभी भी है और सभी भावी भविष्य के लिए आधुनिक मेनफ्रेम का उपयोग मामला होगा - लेकिन यह एक अलग कहानी है)
</ शेख़ी>
द लम्बी कहानी
अब, कहा जा रहा है कि, मेनफ्रेम कोड के कुछ हिस्सों को माइक्रो से नीचे पोर्ट करने की आवश्यकता थी : तारीफ
हम सभी जानते हैं कि सॉफ्टवेयर केवल कुछ जादू नहीं है जो चीजों को करता है, लेकिन व्यापार नियमों, विनियमों और प्रक्रियाओं को संहिताबद्ध करता है। यह वर्कफ़्लो के भीतर निर्णय लेने और निर्णय लेने को औपचारिक बनाता है। और कंपनियों में बहुत कुछ है। जहां छोटी कंपनियां कुछ यादृच्छिक, स्थिति आधारित योजना के साथ जा सकती हैं, वहीं बड़ी कंपनियों के पास ठीक-ठाक नियम होंगे।
लैट ने एक सरल एक ली है, संरचना के लिए एक आदेश संख्या की तरह, वैधता के लिए एक प्रविष्टि की जाँच। एक विकेन्द्रीकृत ग्राहक के साथ, स्पेयर पार्ट्स ऑर्डर करने के लिए कार की मरम्मत की दुकान की तरह, यह प्रवेश करते समय फॉर्म बीप को पहले से ही स्थानीय होना अच्छा होगा, आधे घंटे बाद नहीं जब लॉजिस्टिक्स सिस्टम त्रुटि संदेशों का एक बैच लौटाता है, है ना? यह एक 25 वर्ण अल्फ़ान्यूमेरिक प्रविष्टि है जिसमें बहुत सारे हाइफ़न और एक जैसे हैं। इसकी जाँच करने का एक सटीक क्रम है।
कोई मुद्दा नहीं, सी में आसान किया जा सकता है, है ना? सही है, लेकिन पहले से ही एक मॉड्यूल है, जिसे चेक में COBOL लिखा गया है। और स्रोत कोड के इस एक टुकड़े का उपयोग किया जाता है (या कहा जाता है) जहां भी एक भाग संख्या की जांच होती है। प्रक्रिया प्रबंधन नहीं चाहता कि कंपनी के भीतर कोई भी उस कोड को बायपास करे। इसलिए या तो क्लाइंट डेवलपर्स अपने स्वयं के कार्यान्वयन को बनाने के लिए आने वाले वर्षों के लिए एक कठिन लड़ाई लड़ते हैं , या उस मॉड्यूल को शामिल करते हैं। और यही कारण है कि मेनफ्रेम के लिए मुख्य बफ़र COBOL का मुख्य उपयोग था, संगतता और / या पहुंच के लिए संगतता और एकल स्रोत बनाए रखने के लिए कुछ फ़ंक्शन की प्रतिलिपि बनाना।
Microsoft COBOL आपके PASCAL, C या BASIC प्रोग्राम में शामिल COBOL मॉड्यूल का एक समूह होने के कार्य के लिए काफी ऊपर था। 64 KiB तक सीमित होना कोई बड़ी बात नहीं है, क्योंकि इस तरह के मॉड्यूल में भारी भरकम एप्लिकेशन नहीं होते हैं। बस थोड़े से बंद / पढ़े जाने वाले स्रोत को ही संकलित किया जाता है और सही समय पर बुलाया जाता है।
इतनी लंबी कहानी संक्षेप में, यह (लगभग) पूरे अनुप्रयोगों को माइक्रो में डाउन पोर्ट करने के बारे में कभी नहीं थी, लेकिन माइक्रोफोस (सामने के अंत के रूप में) को एक मेनफ्रेम (सॉफ्टवेयर) वातावरण में एकीकृत करती है।
... अब, दूसरी ओर UNIX में मेनफ्रेम कोबोल अनुप्रयोगों को पोर्ट करना पूरी तरह से एक अलग कहानी है।
संपूर्णता के लिए:
नौकरी नियंत्रण भाषा, जेसीएल। मोटे तौर पर बैश के बराबर?
Err ... नहीं, वास्तव में नहीं। ठीक है, हाँ यह नौकरियों को नियंत्रित करने के बारे में है, लेकिन प्रोग्रामिंग के रूप में ऐसा नहीं है।
कुछ लिनक्स सॉफ्टवेयर में बैश स्क्रिप्ट में काफी कोड होता है, जो एक अलग शेल के साथ प्लेटफॉर्म पर पोर्ट करने के लिए nontrivial प्रयास पैदा करेगा। क्या JCL के संबंध में भी यही सच है?
कम्प्यूटिंग केंद्रों ने हर आवेदन के आसपास एक टन जेसीएल का उपयोग किया। जेसीएल अनिवार्य रूप से प्रसंस्करण के प्रत्येक चरण के बीच पंच कार्ड के ढेर को परिवहन करने के लिए गोंद तर्क है। रहस्यमय, आपको इसके बारे में सोचने की जरूरत है क्योंकि लोग बड़े यांत्रिक कार्ड प्रसंस्करण के बीच गाड़ियां ले जा रहे हैं ... और बाद में टेप और डिस्क ढेर :)
तो नहीं, जेसीएल वास्तव में माइक्रोब पर COBOL के लिए एक मुद्दा नहीं है, क्योंकि यहां हैंडलिंग अलग है। CMD.EXE, पॉवरशेल या BASH की वैसे भी आवश्यकता होगी - यदि बिल्कुल भी।
आरपीजी, रिपोर्ट जनरेशन लैंग्वेज, जो 1959 तक पूरी तरह से चल रही थी। क्रिस्टल रिपोर्ट जैसी किसी चीज के बराबर, जीयूआई के बिना?
बस दूर से। आरपीजी केवल एक रिपोर्ट जनरेटर नहीं है, लेकिन एक पूर्ण लगा प्रोग्रामिंग भाषा है। यह अद्वितीय दर्शन है फिर से पंच कार्ड के आसपास निर्माण होता है। आरपीजी कार्यक्रम अनिवार्य रूप से शाब्दिक प्लगबोर्ड हैं। खैर, कि यह शुरू कर दिया गया है - आजकल यह अधिक जटिल तरीका है।
संभवतया एक विशिष्ट व्यवसाय अनुप्रयोग का पर्याप्त हिस्सा इसमें लिखा जा सकता है?
हाँ। अगर सब नहीं। इसे डेटा फावड़ा के ढांचे के रूप में सोचें।
लेकिन जिस किसी के पास आरपीजी में लिखा सामान था वह पीसी में नहीं बल्कि डाउनसाइज़िंग करते समय सिस्टम / 3x में माइग्रेट हो जाता। कम सॉफ्टवेयर अनुकूलन लागत अब तक उच्च आईबीएम मध्य रेंज की कीमतों से अधिक है।
DB2, एक संबंधपरक डेटाबेस। यह वास्तव में एक समस्या होने की संभावना कम लगती है, आंशिक रूप से क्योंकि यह पहली बार केवल 1983 में जारी की गई थी,
DB2 SQL है और SQL DB2 है। सचमुच।
IMS, एक पूर्व-संबंधपरक डेटाबेस। यह एक समस्या होने की अधिक संभावना है,
IMS डेटा बेस की तुलना में रनटाइम वातावरण और लेनदेन प्रणाली का अधिक है। इसलिए IMS एप्लिकेशन को एक पीसी पर स्थानांतरित करने का कोई मतलब नहीं है। क्या मतलब है (वास्तव में एक बहुत) खरोंच से micros पर ग्राहक अनुप्रयोगों कर रहा है, कोई COBOL शामिल है, कोल्पिनेस के लिए उपर्युक्त modues को छोड़कर। IMS ने संचार समाधान फिर से जल्दी पेश किए।
अन्य प्रमुख सॉफ्टवेयर घटक जिनके बारे में मुझे जानकारी नहीं है?
सीआईसी। तब फिर से, ग्राहक उपयोग के लिए CICS कनेक्टर जल्दी से उपलब्ध थे, इसलिए कोई समस्या नहीं है, जबकि सर्वर साइड इंटरफेस की आवश्यकता नहीं थी।
कोबोल अनुप्रयोगों को आमतौर पर मेनफ्रेम से माइक्रोस तक पोर्ट नहीं किया गया है क्योंकि वे दो विशेषताओं पर भरोसा करते हैं जो कि माइक्रोएस की कमी है।
थ्रूपुट COBOL अनुप्रयोगों को अक्सर एक निश्चित समय में बड़ी मात्रा में डेटा संसाधित करने की आवश्यकता होती है (उदाहरण के लिए एक श्रृंखला में सभी दुकानों के लिए एक दिन की बिक्री का डेटा संसाधित करना)। ये कार्य आम तौर पर I / O बाउंड होते हैं और मेनफ्रेम में लोड को संभालने के लिए विशेष हार्डवेयर (जैसे I / O प्रोसेसर) होते हैं; micros यह नहीं है।
विश्वसनीयता , COBOL अनुप्रयोगों का उपयोग अक्सर उन परिस्थितियों में किया जाता है जहां डाउनटाइम या त्रुटियों को बर्दाश्त नहीं किया जा सकता है। मेनफ्रेम में हार्डवेयर और सॉफ्टवेयर अतिरेक है, ताकि वे विफलताओं को बेहतर ढंग से संभाल सकें; आम तौर पर micros यह नहीं है।
उदाहरण के लिए, टेंडेम का नॉनटॉप प्लेटफॉर्म देखें।
जावा (व्यवसायों के लिए बहुत लोकप्रिय) को कई मेनफ्रेम प्लेटफार्मों में पोर्ट किया गया है। फिर भी, पुराने अनुप्रयोगों को आम तौर पर 1 से फिर से नहीं लिखा जाता है) वे ठीक-ठीक काम करते हैं-और 2) बदलते व्यवहार (नए कीड़े, आदि) का खतरा है।
अलग-अलग चीजें हुईं।
एक, जब मेनफ्रेम को बदल दिया गया था, तो उनके अनुप्रयोगों को नए प्लेटफार्मों के लिए आधुनिक भाषाओं में लिखे गए नए अनुप्रयोगों के साथ बदल दिया गया था। कई आईबीएम मेनफ्रेम को आधुनिक यूनिक्स मशीनों द्वारा पूरी तरह से नए सॉफ्टवेयर अनुप्रयोगों के साथ बदल दिया गया है।
दो, उन लोगों के लिए जो अपने अनुप्रयोगों को फिर से लिखना नहीं चाहते थे, लेकिन प्लेटफ़ॉर्म बदलते हैं, उन्होंने सॉफ्टवेयर चलाने के लिए आभासी वातावरण पर भरोसा किया। हमने IBM सिस्टम की जगह एक नया HP स्थापित किया, और अधिष्ठापन का एक हिस्सा HP पर IBM कोड को चलाने के लिए एक एमुलेटर था। इसलिए, इस मामले में, साइटम को फिर से लिखने की आवश्यकता नहीं है।
असली सवाल यह है कि छोटी मशीनों पर लिखा गया "ग्रीनफील्ड" COBOL क्यों नहीं था। संभवतः यह केवल आधुनिक प्रणालियों, आधुनिक वातावरण का मामला था, जो डेवलपर्स के लिए अधिक मूल्य था, जो कि COBOL की तुलना में उन्हें समय पर दे सकता था।
आईबीएम मेनफ्रेम पर COBOL के लिए सबसे महत्वपूर्ण सहायक सॉफ्टवेयर क्या था?
मैं यह कहने का उपक्रम करूंगा कि यह उन चीजों में से नहीं है जिनका आप उल्लेख करते हैं; मुझे लगता है कि आईबीएम ने "एक्सेस के तरीकों" को कहा था - डेटा संरचनाएं और निम्न स्तर की सिस्टम लाइब्रेरी, जो फ़ाइलों के लिए प्रोग्रामेटिक एक्सेस की अनुमति देती हैं, पहले अनुक्रमिक (टेप पर), बाद में यादृच्छिक (डीएएसडी पर)। COBOL अपने विकास के प्रत्येक चरण (ISAM, VSAM, BDAM इत्यादि) में उपलब्ध पहुँच विधियों के साथ बहुत कसकर एकीकृत होने के लिए विकसित हुआ।
COBOL अनुप्रयोगों का एक बड़ा हिस्सा है जिसे हम आज ईटीएल जॉब कहते हैं: फाइलें पढ़ना, इनपुट रिकॉर्ड को पार्स करना, उनमें हेरफेर करना, एक अलग रिकॉर्ड संरचना के साथ नई फाइलें लिखना। SQL और इंटरैक्टिव I / O क्षमताओं को COBOL में बहुत बाद में जोड़ा गया था।
मिनिकॉम्प्यूटर ऑपरेटिंग सिस्टम ने फ़ाइल एक्सेस के लिए एक अलग, उच्च-स्तरीय अमूर्तता की पेशकश की, जिसे नए प्रोग्रामिंग प्रतिमानों, भाषाओं और उपकरणों की आवश्यकता थी। जब तक विभिन्न COBOL कार्यान्वयन मिनी- और माइक्रो कंप्यूटर प्लेटफ़ॉर्म पर पोर्ट किए गए थे, तब तक "देशी" विकल्प पहले से ही स्थापित हो चुके थे, नई पीढ़ी के प्रोग्रामर और संबंधित प्रौद्योगिकियों को ला रहे थे।
यकीन नहीं होता कि आपने वास्तव में क्या पूछा है।
मैं तब आईबीएम एसई था। कोबोल एक संकलित भाषा है। इसलिए आपको इसके लिए एक कंपाइलर की जरूरत है। कंपाइलर को एक ऑपरेटिंग सिस्टम की आवश्यकता होती है। ऑपरेटिंग सिस्टम को मेनफ्रेम कंप्यूटर की आवश्यकता होती है। मेनफ्रेम कंप्यूटर को इसे चलाने के लिए और इसे चलाने के लिए बिजली के लिए FEs की आवश्यकता होती है और इसे एक विशेष कमरे में ठंडा करने की आवश्यकता होती है ताकि नीचे केबल बिछाने की अनुमति मिल सके।
कई मेनफ्रेम थे जो कोबोल चलाते थे। कई ऑपरेटिंग सिस्टम थे जो कोबोल चलाते थे, हालांकि उनमें से केवल दो मुख्य वर्ग: बिग ओज़ और डॉस। हो सकता है कि एस / 20 में कोबोल के साथ एक ऑप्सिस भी था। सुविधाओं की विभिन्न पूर्णता के साथ कई संकलक थे। फिर से ज्यादातर डॉस और ओएस आधारित। एस / 20 के बारे में अनिश्चित; और बाद में मुझे लगता है कि केवल 3 आरपीजी था।
यदि आप एक छोटा सा सीधा सवाल पूछ सकते हैं तो हम आपको बेहतर जवाब दे सकते हैं।
IMS डेटा बेस की तुलना में रनटाइम वातावरण और लेनदेन प्रणाली का अधिक है।
मुझे उस पर असहमत होना पड़ेगा। IMS एक गैर-संबंधपरक डेटाबेस है (श्रेणीबद्ध, अगर मैं सही ढंग से अपने ग्रेड स्कूल पाठ्यक्रम को याद करता हूं)। यह लगभग अप्रयुक्त है, हर कोई संबंधपरक डेटाबेस (एसक्यूएल शैली) पर चला गया है।
शायद आप वीएमएस के तहत सीएमएस (कन्वर्सेशनल / कैंब्रिज मॉनिटर सिस्टम), या एमवीएस के तहत टीएसओ (टाइम शेयर ऑप्शन, मुझे लगता है) सोच रहे थे?