2012-05-15 19 views
6

वर्तमान में हमारे पास ओपनवीएमएस (इंटीग्रटी/इटेनियम) पर चलने वाले कोबोल में लिखा गया एक बड़ा व्यवसाय-महत्वपूर्ण अनुप्रयोग है।इटेनियम से दूर जाना

महीने बीतने के बाद, इटेनियम आर्किटेक्चर के जीवनकाल के बारे में अधिक से अधिक अटकलें होती हैं। खुले में कुछ भी नहीं कहा जाता है, लेकिन this और this जैसे लेख एक चिंताजनक तस्वीर पेंट करते हैं। यद्यपि मुझे इसका समर्थन करने के लिए कुछ भी अधिकारी नहीं मिल सकता है, इसके अलावा एचपी की हमारी कंपनी के गलियारे में ओपनवीएमएस और एचपी कोबोल डालने के साथ-साथ इसके साथ-साथ कुरकुरा भी हो रहा है।

मुझे विश्वास नहीं है कि हम इसमें अकेले हैं।

तरह से मैं इसे देख, उसके लिए कुछ विकल्प हैं:

  1. कुछ पुराने हार्डवेयर का अनुकरण और CHARON-VAX या CHARON-AXP की तरह एक उत्पाद का उपयोग उस पर आवेदन चलाते हैं। जिस तरह से मैं इसे देखता हूं, पेशेवर यह हैं कि प्रक्रिया अपेक्षाकृत दर्द रहित होनी चाहिए, खासकर यदि 64-बिट (एएक्सपी) विकल्प का उपयोग किया जाता है। संभावित विपक्ष प्रदर्शन में गिरावट है (हालांकि इसे तेज और तेज़ हार्डवेयर द्वारा ऑफसेट किया जाना चाहिए);
  2. एचपी कोबोल-आधारित एप्लिकेशन को कोबोल की एक और आधुनिक बोली, जैसे Visual COBOL पर पोर्ट करें। पेशेवर, तब, तथ्य यह है कि पोर्टिंग प्रयास अपेक्षाकृत कम है (यह अभी भी COBOL है) और तथ्य यह है कि कोई यूनिक्स या विंडोज प्लेटफ़ॉर्म पर एप्लिकेशन चला सकता है। विपक्ष यह है कि यद्यपि आप कोबोल पोर्ट कर रहे हैं, तथ्य यह है कि आप एक अलग ऑपरेटिंग सिस्टम पर पोर्ट कर रहे हैं, जिससे चीजें मुश्किल हो सकती हैं (esp। अगर ओपनवीएमएस-विशिष्ट निर्भरताएं हैं);
  3. स्वचालित रूप से कोबोल को जावा जैसी अधिक आधुनिक भाषा में अनुवादित करें। यह सभी विरासत मुद्दों से तुरंत एक को मुक्त करने का स्पष्ट लाभ है, एक में गिरावट आई है: हार्डवेयर समर्थन, ऑपरेटिंग सिस्टम समर्थन, और विशेष रूप से प्रशासकों और प्रोग्रामर ढूंढना। यह एक बड़ी नौकरी होने के अलावा, एक स्पष्ट नकारात्मक तथ्य यह है कि कोई गैर-मूर्खतापूर्ण जावा (या जो भी लक्ष्य भाषा आखिरकार चुना जाता है) के साथ समाप्त हो जाएगा; तर्कसंगत रूप से, यह ऐसा कुछ है जिसे समय के साथ बढ़ाया जा सकता है।
  4. जमीन से ऊपर (स्वाभाविक रूप से, आधुनिक तकनीकों का उपयोग करके) एक पुनर्लेखन। कोई भी जिसने यह किया है जानता है कि यह कितना महंगा और समय लेने वाला है। मैंने केवल सूची को पूरा करने के लिए इसे शामिल किया है :)

ध्यान दें कि स्वामित्व डीबीएमएस पर कोई निर्भरता नहीं है; डेटाबेस ISAM फ़ाइल-आधारित है।

तो ... मेरे सवाल है:

दूसरों को क्या कर रहे हैं इटेनियम के आसन्न अप्रचलन कारोबार निरंतरता बनाए रखने के लिए जब चुनाव के अपने मंच ओपन VMS और कोबोल है कर रही के साथ सामना?

अद्यतन:

हम चाहते हैं कि वफ़ादारी/इटेनियम/ओपन VMS का समर्थन किया जाएगा कम से कम हमारे स्थानीय हिमाचल प्रदेश प्रतिनिधि से एक अधिकारी आश्वासन ऊपर 2022 तक मुझे लगता है कि इसका मतलब है कि इस पूरे मुद्दे के बारे में कम है पड़ा है मंच, और भाषा (COBOL) के बारे में और अधिक।

+2

यह एक बदसूरत स्थिति है। मैं अपने ग्राहकों के लिए किस प्रकार की माइग्रेशन रणनीति विकसित कर रहा हूं, यह जानने के लिए माइक्रोफोकस से संपर्क करने का प्रयास करूंगा। मेरा मानना ​​है कि माइक्रोफोकस ने सीओबीओएल अनुप्रयोगों को इटेनियम प्लेटफॉर्म पर माइग्रेशन को बढ़ावा दिया। और इसके कारण, मुझे संदेह है कि वे किसी भी व्यक्ति के रूप में कड़ी मेहनत करेंगे क्योंकि इटेनियम से माइग्रेशन पथ को "अगली और सबसे बड़ी चीज़" - जो कुछ भी हो सकता है। उनके पास उतना ही ढीला है जितना कि किसी को भी पता चलता है कि उनका जहाज कहां नौकायन कर रहा है और शायद सवारी कर रहा है। – NealB

+0

ऐसा लगता है कि आपको ओपनवीएमएस को आगे बढ़ने पर गंभीरता से विचार करना होगा। आपको एचपी से पूछना चाहिए कि उनके पास यूनिक्स उत्पाद है जो एचपी कोबोल का समर्थन करता है। इसके अलावा, नीलबी के सुझाव के अलावा, आपको अवेन्ट के साथ भी जांच करनी चाहिए, वे दो अलग-अलग कोबोल अनुपालन (http://www.veryant.com) – colemanj

उत्तर

1

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

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

दान

0

लगता कोबोल की तरह मुख्य निर्भरता है कि आप चिंतित रहता है। मैं इस तस्वीर में Itaniumand Itanium + OpenVMS बस एक मंच है।

आप निश्चित रूप से ओपनवीएमएस पर मिशन-महत्वपूर्ण सामग्री अकेले नहीं चल रहे हैं। एचपी साइट में ओपनवीएमएस रोडमैप (अल्फा और इंटीग्रटी दोनों) है, वर्तमान में समर्थन 2015 तक फैला है। ओरेकल हाल ही में विभिन्न डोमेन में इसकी सन संपत्ति का लाभ उठाने का प्रयास कर रहा है।

किसी भी मामले में, यदि आपकी चिंताएं पर्याप्त हैं (सुनिश्चित करें कि हम सभी COMPAQ, फिर एचपी, वैक्स >> अल्फा >> अतीत में इटेनियम संक्रमण) के बारे में चिंतित हैं, तो COBOL निर्भरता को टालने का समय है।

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

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

कुछ भी नहीं है, हालांकि स्पष्ट रूप से जोखिम भरा है: ओपनवीएमएस प्लेटफॉर्म भरोसेमंद साबित हुए हैं, इसलिए वैकल्पिक रूप से, एक विश्वसनीय तृतीय-पक्ष समर्थन कंपनी ढूंढना आपके भविष्य के हार्डवेयर आकस्मिकता को बढ़ा सकता है।

+0

हाथ से एक बड़े आवेदन को पुनर्लेखन करना आमतौर पर आपदा का मार्ग है। इसका महंगा, कठिन करना, काफी समय लगता है, और नया एप्लिकेशन "कभी नहीं" चल रहे एप्लिकेशन के साथ पकड़ता है ताकि वह इसे विस्थापित नहीं कर सके। यदि आप भाग्यशाली हैं तो आप यह सब खत्म कर लेंगे।व्यावहारिक क्या है बड़े पैमाने पर स्वचालित माइग्रेशन, COBOL-for-whatever-ecosystem (आपका केस: ओपनवीएमएस) को COBOL-for-different-ecosystem और/या विभिन्न भाषाओं में। ये दर्दनाक भी हैं, लेकिन उसी तरह नहीं। Http://stackoverflow.com/questions/3455456/how-to-translate-between-programming-languages/3460977#3460977 देखें –

0

इस गर्मी के रोलिंग रोडमैप ओपनवीएमएस को एक उत्कृष्ट विचार की तरह बंद कर देता है।

यह देखते हुए कि कोबोल का समर्थन करने के लिए लोगों को खोजने में दुनिया में कितना COBOL मौजूद है, भविष्य के लिए कोई समस्या नहीं होगी। जैसा कि ऊपर बताया गया है, अन्य प्लेटफार्मों पर कोबोल कंपाइलर हैं। समस्या ओपनवीएमएस सिस्टम सर्विस कॉल और आपके एप्लिकेशन का उपयोग करने वाले डीईसी भाषा एक्सटेंशन में निहित है। आप इस बात का जिक्र नहीं करते कि आपका डेटा कहां संग्रहीत है, इसलिए आपके COBOL RMS का सबसे खराब मामला उपयोग करता है। एक ऐसी कंपनी है जो लिनक्स और यूनिक्स पर कई ओपनवीएमएस सिस्टम सेवाओं का कार्यान्वयन प्रदान करती है। किसी अन्य ऑपरेटिंग सिस्टम को पोर्ट करते समय उन सेवाओं को प्रतिस्थापित करने की आवश्यकता नहीं है, जटिलता को कम कर सकते हैं। Sector7.com देखें।

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