2009-10-01 4 views
11

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

उत्तर

24

पृथ्वी पर क्यों आपको लगता है कि उनके पास बग नहीं है?

आईबीएम में विशाल बग रिपोर्टिंग और रिज़ॉल्यूशन (पीएमआर, एपीएआरएस और पीटीएफ) के लिए समर्थन आधारभूत संरचना है, जिसका भारी उपयोग किया जाता है।

मेनफ्रेम सॉफ़्टवेयर जो कई वर्षों तक छुआ नहीं गया है, निश्चित रूप से अच्छी तरह से समझा जाएगा (कम से कम इसकी idiosyncrasies के संदर्भ में) और संभवतः कई बग्स को तय या काम किया होगा। आजकल सभी नई चीजें विकसित की जा रही हैं, वास्तव में जीए (सामान्य उपलब्धता) से कम से कम GA + 36 महीने तक बग और पैच की एक निश्चित संख्या की योजना बनाते हैं। वास्तव में, आईबीएम में मेरा एक पूर्व मालिक लाइन के साथ योजनाबद्ध बग के आंकड़े प्रदान करने के लिए मजबूर होने के लिए मजबूर होना चाहता था: "हम की योजना बना रहे हैं ताकि कोई भी बग हो सके"।

मेनफ्रेम रास सिद्धांतों (विश्वसनीयता, उपलब्धता और serviceability) जो सबसे डेस्कटॉप हार्डवेयर और सॉफ्टवेयर कभी के लिए कामना कर सकता है परे espouses - कि निश्चित रूप से केवल मेरी राय है, लेकिन मैं कर रहा हूँ सही :-)

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

केवल बग-मुक्त सॉफ़्टवेयर जारी करने पर बहुत अधिक प्रयास और लागत खर्च की गई है, लेकिन यहां तक ​​कि उन्हें हर समय सही नहीं लगता है।

+6

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

+1

@Modan, * इसके foibles * के संदर्भ में। इसके * internls * को समझा नहीं जा सकता है (स्रोत भी चलाया जा सकता है), लेकिन अगर पिछले बीस वर्षों में सभी कचरा डेटा के साथ इसका पालन नहीं किया गया है तो यह उस समय के अधीन होगा, यह अविश्वसनीय रूप से असंभव है कल शुरू करो। और यदि यह abended था, तो आप एक कामकाज मिल जाएगा या इसे बदल दिया होगा। – paxdiablo

0

ओह, उनके पास निश्चित रूप से बग हैं - कुछ और मनोरंजक उदाहरणों के लिए thedailywtf.com देखें। उस ने कहा, "मेनफ्रेम" अनुप्रयोगों में से अधिकांश आज देखता है कि सभी कंकों को काम करने के लिए 30 साल हैं, इसलिए पिछले कुछ वर्षों में बनाए गए अधिकांश अनुप्रयोगों पर उनके पास थोड़ा सा फायदा है।

+0

कैसे सभी नए मेनफ्रेम अनुप्रयोगों उनके अवरोधों को हटाने के काम मिलता है? –

+0

@ जोजित्ज़ेलबर्गर: वे नए नहीं बना रहे हैं, आम तौर पर पुराने ईडीआई इंटरफेस को किसी प्रकार की वेब सेवा स्टैक में लपेटते हैं। अस्तित्व में एक बग के बिना शायद और वहां एक गैर-तुच्छ अनुप्रयोग नहीं है। –

+1

एमवीएस/ओएस 3 9 0/जेओएस-सीआईसीएस/टीएस-कोबोल एप्लिकेशन प्लेटफार्म की मौत की अफवाहें तब तक चल रही हैं जब तक ऐप्पल कंप्यूटर और उनके आला मंच की मौत की अफवाहें चल रही हैं। मेनफ्रेम दुनिया में बहुत नया विकास है। क्षमा करें अगर प्रारंभिक टिप्पणी को पहचानने के लिए पर्याप्त कटाक्ष के साथ ड्रिप नहीं किया गया था। –

11

मुख्य फ्रेम सॉफ्टवेयर में कोई बग नहीं है, केवल विशेषताएं।

+5

सामान्य डेस्कटॉप अनुप्रयोगों के विपरीत, जिनके पास * अनियंत्रित * विशेषताएं हैं। – voyager

+3

सामुदायिक विकी का प्रीपेप्टिव उपयोग। बहुत बढ़िया। – Kobi

+0

यह प्रश्न का उत्तर नहीं प्रदान करता है। किसी लेखक से स्पष्टीकरण की आलोचना या अनुरोध करने के लिए, अपनी पोस्ट के नीचे एक टिप्पणी छोड़ दें। –

0

जबकि मुझे मेनफ्रेम के साथ अनुभव नहीं है, मुझे लगता है कि यह आपके द्वारा बनाया गया पहला बिंदु है: सॉफ्टवेयर दशकों से आसपास रहा है। अधिकांश शेष बग का काम किया जाएगा।

इसके अलावा, वाई 2 के जैसे फायरस्कोस को न भूलें। लोगों की सभी बगों पर ठोकर खाई गई है, और 20 वर्षों में ज्यादातर स्थितियां शायद हुईं। लेकिन हर बार थोड़ी देर में, एक नई स्थिति साथ आने का प्रबंधन करती है जो 20 साल के पुराने सॉफ्टवेयर को काम करना बंद कर देती है।

(इसका एक और दिलचस्प उदाहरण है, मुझे विश्वास है कि बीएसडी यूनिक्स। यह एक साल या उससे पहले पाया गया था, और यह बिना किसी के चलने के 20 साल तक रहा है)।

0

मुझे लगता है कि प्रोग्रामिंग सिर्फ एक उन्नत क्षेत्र था जिसे केवल चयनित इंजीनियर ही इसमें काम कर सकते थे। प्रोग्रामिंग की दुनिया अब हर पहलू में कम प्रवेश बाधाओं के साथ बहुत बड़ी है।

+0

समीक्षा द्वारा उत्पन्न की गई थी क्योंकि कोई औपचारिक प्रशिक्षण वाले कोबोल प्रोग्रामर के पास प्रवेश के लिए उच्च बाधा थी? अक्सर यह मेल रूम चलाने से एक पदोन्नति थी ... –

5

मेनफ्रेम सॉफ़्टवेयर पर बग की पूरी तरह से असीमित, वे डेवलपर्स के अपेक्षाकृत छोटे समूह के कारण उतनी ही प्रकाशित नहीं हैं। बस किसी ऐसे व्यक्ति से पूछें जो मेनफ्रेम विकास करता है कि वे दैनिक आधार पर कितने ABENDS देखते हैं!

+0

ABEND! मुझे अभी भी यह कहते हैं कि समय-समय पर और कुख्यात 0C4 –

+0

// SYSABEND डीडी SYSOUT = ए - बहुत, बहुत लंबा दिन शुरू होता है। –

+1

डेवलपर्स प्रभावित नहीं हैं, यह ग्राहक हैं। और मेनफ्रेम सॉफ़्टवेयर में बग से प्रभावित लोगों की संख्या * विशाल * हो सकती है - जैसे हाल ही में ऑस्ट्रेलिया में हाल ही में बैंक की हार, जहां नेट पर कोई खाता जानकारी उपलब्ध नहीं थी और कई ऑनलाइन लेन-देन दिनों के लिए देरी हुई थीं। आपको लगता है कि ऑनलाइन पीसी बैंकिंग बुनियादी ढांचे, एसक्यूएल सर्वर के कुछ पीसी पर पिछली छोर पर क्या है? :-) – paxdiablo

2

मैंने डीबगर्स का उपयोग करना और बड़े लोहा मेनफ्रेम पर कोर डंप का विश्लेषण करना सीखा। मेरा विश्वास करो वे केवल बग के कारण आए थे। आप बस सादा गलत हैं।

हालांकि मेनफ्रेम आर्किटेक्चर को उच्च तनाव (अच्छी तरह से गैर मेनफ्रेम सिस्टम कहने की तुलना में स्थिरता के तहत स्थिरता के लिए डिज़ाइन किया गया है) ताकि आप तर्क दे सकें कि वे इस तरह बेहतर हैं। लेकिन कोड के अनुसार? ना बग अभी भी हैं ...

6

मैं मेनफ्रेम ऐप्स पर काम करता था। पहले के ऐप्स में कई कीड़े नहीं थी क्योंकि उन्होंने बहुत कुछ नहीं किया था। हमने सैकड़ों लिखा है अगर फोरट्रान की हजारों लाइनें एक्सेल में कुछ सूत्रों के साथ आप क्या करेंगे। लेकिन जब हम उन कार्यक्रमों से गए जो कार्ड 1 के कॉलम 12-26 में एक मान डालकर और कार्ड 2 के कॉलम 1-5 में एक और मूल्य डालकर इनपुट इनपुट प्राप्त करते थे, जो इंटरैक्टिव आईएसपीएफ स्क्रीन या प्रकाश से इनपुट लेते थे एक Calcomp 1012 प्लॉटटर या एक Tektronix 4107 टर्मिनल पर कलम और आउटपुट, बग गिनती ऊपर चला गया।

0

मुझे लगता है कि यह कुछ चीजें हैं। पहला यह है कि फिक्स-ए-बग-रीकंपाइल का चक्र आमतौर पर मेनफ्रेम में अधिक महंगा था। इसका मतलब है कि प्रोग्रामर सिर्फ कोड को ढल नहीं सकता था और "यह देखता है कि यह काम करता है"। इन-हे-हेड संकलन और रनटाइम सिमुलेशन करके आप संकलक को पकड़ने की अनुमति देने से अधिक बग स्पॉट कर सकते हैं।

दूसरा, हर कोई और उनका भाई "प्रोग्रामर" नहीं था। वे आमतौर पर अत्यधिक प्रशिक्षित विशेषज्ञ थे। अब कार्यक्रम हाईस्कूल डिप्लोमा के साथ अपने बेसमेंट में बैठे लोगों से आते हैं। कुछ गलत नहीं है उसके साथ!!! लेकिन इसमें अधिक बग होते हैं जो अभियंता 20 साल तक पेशेवर रूप से कर रहा है।

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

परिपक्वता निश्चित रूप से एक कारक है। एक कोबोल क्रेडिट-कार्ड प्रोसेसिंग प्रोग्राम जिसे 20 साल पहले लिखा गया था और किसी भी कार्यक्रम के 0.1 संस्करण की तुलना में समस्या को कम करने की संभावना कम है। बेशक, यह मुद्दा है कि इन पुराने पुनर्लेखित अनंत काल कार्यक्रम आमतौर पर स्पेगेटी कोड को समाप्त करते हैं जो बनाए रखना लगभग असंभव है।

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

2

मेनफ्रेम अनुप्रयोग सॉफ्टवेयर (के रूप में ऑपरेटिंग सिस्टम के खिलाफ) के साथ मेरा अनुभव बहुत पुराना हो चुका है, लेकिन मेरी याद है कि अनुप्रयोगों के बहुमत बैच अनुप्रयोग जो कर रहे हैं, तार्किक रूप से, बहुत सरल हैं:

क) पढ़ें कोई इनपुट फ़ाइल
ख) प्रत्येक रिकॉर्ड प्रक्रिया (यदि आप साहसी महसूस कर रहे हैं, एक डेटाबेस को अद्यतन)
ग) कोई आउटपुट फ़ाइल लिखें

कोई उपयोगकर्ता इनपुट घटनाओं के बारे में चिंता करने की, नौकरी की निगरानी के लिए योग्य ऑपरेटरों की एक टीम जैसे ही यह चलता है, बाहरी प्रणालियों, आदि के साथ कम बातचीत, इत्यादि।

अब व्यवसाय तर्क जटिल हो सकता है (विशेष रूप से यदि यह COBOL 68 में लिखा गया है और डेटाबेस संबंधपरक नहीं है) लेकिन यदि आपको ध्यान केंद्रित करना है, तो विश्वसनीय सॉफ्टवेयर बनाना आसान है।

+0

"बैच" बड़े सिस्टम में अलग-अलग अर्थों पर पड़ता है।बैच प्रोसेसिंग (छोटे हिस्से में) को नौकरी बनाम अधिकतम या पहचान किए गए CPU समय को बाधित करने के लिए ट्यून किया गया है, जो कि एक सामान्य यूनिक्स सिस्टम में क्या हो सकता है, बाधित हो रहा है और पुन: निर्धारित किया जा रहा है। ऊपर दिए गए 3 कदम वही तरीके से हैं जो एक ही समय में प्रत्येक सिस्टम पर काम करते हैं। आज के मेनफ्रेम बस सबकुछ के बारे में करते हैं जो हम आज कहीं और कर रहे हैं। – Xailor

1

मैंने कभी भी मेनफ्रेम के लिए सॉफ़्टवेयर पर काम नहीं किया है, लेकिन मेरे पिता 1 9 70 के दशक में एक कोबोल प्रोग्रामर थे।

जब आपने उन दिनों में सॉफ़्टवेयर लिखा था, तो बग ढूंढना आपके स्रोत कोड को संकलित करने और त्रुटि संदेशों को देखने में आसान नहीं था, संकलक आपके पास वापस थूकता है या आपका प्रोग्राम चला रहा है और यह देख रहा है कि यह गलत क्या कर रहा था। एक टाइपिस्ट को पंच कार्ड में प्रोग्राम को पंच करना होता था, जिसे तब कंप्यूटर में पढ़ा जाएगा, जो आपके प्रोग्राम के परिणामों को प्रिंट करेगा।

मेरे पिता ने मुझे बताया कि एक दिन कोई कागज के बक्से से भरे गाड़ी के साथ आया था और वह कमरे के दरवाजे के बगल में रखता था जहां वह काम कर रहा था। उसने पूछा "वह क्या है ?!", और उस आदमी ने उसे बताया "यह आपके कार्यक्रम का आउटपुट है"। मेरे पिता ने एक गलती की जिसने कार्यक्रम को पेपर के ढेर पर बड़ी मात्रा में गंदगी मुद्रित करने का कारण बताया जो पूरे पेड़ का उपयोग कर सकता था।

आपको लगता है कि जिस तरह से अपनी गलतियों से जल्दी सीख ...

संबंधित मुद्दे

 संबंधित मुद्दे