आईबीएम सिस्टम / 360 - विफलता कहानी

मैं आईबीएम सिस्टम / 360 के बारे में लेखों की अपनी श्रृंखला जारी रखता हूं (सिस्टम के बारे में पहला भाग , आर्किटेक्चर के बारे में दूसरा भाग )। कई दिलचस्प विषय अप्रभावित रहे, और उनमें से पहला था सिस्टम / 360 ऑपरेटिंग सिस्टम, विशेष रूप से उनके विकास का ऐतिहासिक पहलू।



1960 के दशक की शुरुआत तक, आईबीएम के "शक्तिशाली" और "बजट" समाधान असंगत थे। पोर्टिंग कार्यक्रम कठिन था, और कभी-कभी पूरी तरह से असंभव था। यह कई कारणों के कारण था, ऑपरेटिंग सिस्टम के अंतर से बाह्य उपकरणों में अंतर तक। अब ऐसा प्रतीत होता है कि स्वयं स्पष्ट है - विभिन्न सॉफ्टवेयर और हार्डवेयर घटकों की अनुकूलता, तब पूरी तरह से वैकल्पिक थी। यह सिस्टम / 360 के विकास के दौरान था कि कंपनी के इंजीनियरों ने फैसला किया कि इस तरह के दृष्टिकोण से विकास और आगे के रखरखाव की लागत में काफी वृद्धि होगी, और नई प्रणाली को मानकीकृत करने का निर्णय लिया गया, जिससे कार्यक्रमों और कंप्यूटर सहायता के पोर्टिंग को सरल बनाया जा सके।



प्रारंभ में, यह नौकरियों के बैच प्रसंस्करण के साथ एक नए ऑपरेटिंग सिस्टम के साथ सिस्टम / 360 कंप्यूटरों की आपूर्ति करने की योजना बनाई गई थी। सीधे शब्दों में कहें, प्रत्येक प्रोग्राम जिसे चलाने की आवश्यकता होती है, उसे "पैकेज" के रूप में वर्णित किया जाता है - यह प्रोग्राम और इनपुट डेटा का एक सेट है। इन पैकेटों को संसाधनों की प्राथमिकता और उपलब्धता के आधार पर क्रमिक रूप से संसाधित किया जाता है। इस दृष्टिकोण ने हमें मेनफ्रेम की योजना में मानवीय भागीदारी को कम करने और इसके भार को अनुकूलित करने की अनुमति दी, इस प्रकार ओवरहेड को कम किया। ऑपरेटिंग सिस्टम को OS / 360 कहा जाना था।



इस ओएस के डेवलपर्स ने खुद को अविश्वसनीय रूप से महत्वाकांक्षी कार्य निर्धारित किए जो पहले हल नहीं किए गए थे। यह ऑपरेटिंग सिस्टम "मल्टीप्रोग्रामिंग" के लिए समर्थन प्रदान करने वाला था। धीमी परिधीयता के साथ, एक समय में केवल एक कार्यक्रम को निष्पादित करने के बाद लगातार डाउनटाइम होता है जब सिस्टम बाहरी डिवाइस से कुछ डेटा की प्रतीक्षा कर रहा था। इसलिए, आधुनिक अतुल्यकालिक प्रोग्रामिंग के समान एक दृष्टिकोण का उपयोग किया गया था। कई कार्यक्रमों को मेमोरी में लोड किया गया था और उनमें से पहले निष्पादन के लिए लॉन्च किया गया था। यदि एक लंबा इंतजार आवश्यक था, तो वर्तमान कार्यक्रम का संदर्भ सहेजा गया था, और नियंत्रण को अगले एक में स्थानांतरित कर दिया गया था, जो काम कर सकता था जबकि पहला डेटा के लिए इंतजार कर रहा था। इस मामले में ऑपरेटिंग सिस्टम को निरंतर नियंत्रण के तहत सब कुछ रखना था, डाउनलोड किए गए कार्यक्रमों को अन्य कार्यक्रमों की विफलताओं से बचाने और संसाधनों तक पहुंच को नियंत्रित करना था। यह सब आभासी स्मृति की अवधारणा की कमी से जटिल था। ऑपरेटिंग सिस्टम को लाइन के सभी मॉडलों पर काम करना चाहिए था, इसलिए कॉन्फ़िगरेशन 16 केबी से लेकर 1 एमबी तक था, और ऑपरेशन की गति प्रति सेकंड कई हजार ऑपरेशन से लेकर आधा मिलियन तक थी। साथ ही, ऑपरेटिंग सिस्टम को सभी कार्यक्रमों की जरूरतों को पूरा करना था, जो कि जटिल गणितीय गणनाओं से शुरू होता था, जो लगभग कभी बाहरी ड्राइव का उपयोग नहीं करते थे, और साधारण DBMS एनालॉग्स के साथ समाप्त होते थे जो पूरी तरह से I / O ऑपरेशन पर आधारित थे।







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



कई मध्यवर्ती विकल्प विकसित किए गए हैं।



BOS / 360 (बेसिक ओएस) - सरलतम कम-अंत मॉडल के लिए एक प्रणाली।



टीओएस / 360 (टेप ओएस) - एक चुंबकीय टेप से लोड करने के साथ संशोधनों के लिए प्रणाली।



डॉस / 360 (नाम के बावजूद, परिचित x86-युग डॉस से कोई लेना-देना नहीं था) - अधिकांश मध्यम और शक्तिशाली कॉन्फ़िगरेशन के लिए "मुख्य" संस्करण।



पीसीपी (प्राथमिक नियंत्रण कार्यक्रम) वह है जिसे अब हम पूर्ण ओएस / 360 के "बीटा संस्करण" के रूप में कहेंगे, जो बहुभुज का समर्थन नहीं करता था।







श्रृंखला / 360-67 (यदि आप लेख के पहले भाग को पढ़ते हैं, तो आपको याद रखना चाहिए कि वर्चुअल मेमोरी की अवधारणा इस प्रणाली में दिखाई देती है) टीएसएस / 360 (टाइम शेयरिंग सिस्टम) की रिहाई की योजना बनाई गई थी। जैसा कि नाम से ही स्पष्ट है कि यह संस्करण टाइम-शेयरिंग मोड को सपोर्ट करने वाला था। इस ऑपरेटिंग सिस्टम के परीक्षण संस्करण बड़े कॉर्पोरेट ग्राहकों के लिए परीक्षण के लिए दिए गए थे, लेकिन समीक्षा नकारात्मक थी, और ओएस पहले से ही "देर से" बाजार की स्थिति को ध्यान में रखते हुए था, इसलिए टीएसएस / 360 को रद्द कर दिया गया था। इस समय तक, आईबीएम के कैम्ब्रिज रिसर्च सेंटर में विकसित किया जा रहा सीपी -67 ओएस पहले से ही पर्याप्त रूप से डिबग किया गया था। सीपी -67 इतना स्थिर था कि आईबीएम ने इसे ग्राहकों को प्रदान करना शुरू कर दिया, हालांकि समय साझा करने के समर्थन के साथ ओएस के रूप में "वारंटी की छूट" के तहत। इस ऑपरेटिंग सिस्टम के आगे के विकास ने इस तथ्य को जन्म दिया कि इसने VM / 370 और फिर z / VM को आधार बनाया।



"



OS / 360 को विकसित करते समय IBM को जो समस्याएँ हुईं, वे इतनी बड़ी थीं कि उन्होंने "सॉफ्टवेयर इंजीनियरिंग" के विकास को उस रूप में दिया, जिस रूप में हम इसे जानते हैं। तब यह स्पष्ट हो गया था कि इन प्रक्रियाओं के सॉफ्टवेयर विकास और प्रबंधन संसाधन-गहन विषय हैं, जिनके लिए एक नियंत्रित परिणाम प्राप्त करने के लिए एक वैज्ञानिक दृष्टिकोण लागू किया जाना चाहिए।



वरिष्ठ ओएस / 360 विकास परियोजना प्रबंधक, जो व्यक्तिगत रूप से सब कुछ के लिए जिम्मेदार था, एक पुस्तक लिखी जो सॉफ्टवेयर विकास प्रबंधकों के लिए लगभग एक बाइबल बन गई है (जैसा कि लेखक ने कहा, "हर कोई इसे पढ़ता है, लेकिन कोई भी इसका अनुसरण नहीं करता है")। जी हां, हम बात कर रहे हैं फ्रेडरिक ब्रूक्स और उनकी किताब माइथिकल मैन-मंथ की।



ब्रूक्स के सभी सिद्धांतों में से, निम्नलिखित दो ओएस / 360 परियोजना के सार को स्पष्ट रूप से दर्शाते हैं।



किसी परियोजना में संसाधन (मानव संसाधन सहित) हमेशा अपने समय में कमी की ओर नहीं ले जाता है, अक्सर प्रभाव विपरीत भी हो सकता है। जैसा कि पुस्तक में कहा गया है, अल्गोल कंपाइलर के विकास में हमेशा छह महीने लगते हैं, भले ही इसमें कितने भी प्रोग्रामर शामिल हों।



एक सफल प्रणाली का नया संस्करण अक्सर विफलता के लिए बर्बाद होता है, क्योंकि डेवलपर्स उपयोगकर्ताओं की सभी इच्छाओं को महसूस करने की कोशिश करेंगे। ब्रूक्स ने इसे "दूसरा सिस्टम प्रभाव" कहा।







जैसा कि आप देख सकते हैं, एक तरफ, ओएस / 360 के मुख्य संस्करण का विकास, अगर यह पूरी तरह से विफल नहीं हुआ, तो इसके बहुत करीब है। दूसरी ओर, आईबीएम ने इसके बावजूद सिस्टम / 360 को सफल बनाने में कामयाबी हासिल की, और इससे प्राप्त सबक सॉफ्टवेयर विकास के लिए आधुनिक दृष्टिकोणों की नींव बन गए।



जारी रखा जाए