मेनफ़्रेम COBOL प्रोग्रामर मां के साथ एक इंटरव्यू (2016)

 (substack.com/ezali)
2 पॉइंट द्वारा GN⁺ 2023-12-15 | 1 टिप्पणियां | WhatsApp पर शेयर करें

मेनफ़्रेम COBOL प्रोग्रामर मां के साथ इंटरव्यू

  • मां के जन्म से पहले से ही वह EU के सबसे बड़े बैंकों में से एक में काम कर रही हैं।
  • बैंक प्रोग्रामिंग की दुनिया, ज्यादातर लोगों की परिचित दुनिया से पूरी तरह अलग है।
  • अगर मां और उनकी टीम काम छोड़ दें, तो बैंक कुछ ही हफ्तों में ढह जाएगा।

1991

  • मां ने Nordbanken (अब Nordea) में आंतरिक प्रशिक्षण शुरू किया।
  • उन्होंने कई तरह के टेस्ट दिए और IQ टेस्ट, मनोवैज्ञानिक परीक्षण, और मल्टीटास्किंग टेस्ट पास किए।
  • IBM मेनफ़्रेम COBOL प्रोग्रामर के रूप में शुरुआत की, और 25 साल बाद भी उसी बैंक में वही काम कर रही हैं।

COBOL

  • COBOL, functional Haskell या concurrency वाले Golang जैसी कोई शानदार प्रोग्रामिंग भाषा नहीं है।
  • COBOL एक imperative, procedural भाषा है, और 2002 से object-oriented भी है।
  • मेनफ़्रेम प्रोग्रामिंग के संदर्भ में COBOL जानने वाले लोग बहुत कम हैं।

डेटाबेस

  • मुख्य डेटाबेस IMS कहलाता है, जो IBM ने Apollo program के लिए बनाया गया एक hierarchical डेटाबेस है।
  • DB2 पर माइग्रेशन की कोशिश चल रही है, लेकिन यह कई वर्षों का काम है।
  • DB2 डेटाबेस में इस समय लगभग 10TB डेटा है।

बैच

  • सिस्टम का लगभग 80% हिस्सा batch jobs से बना है।
  • batch jobs तय समय या अंतराल पर चलती हैं, और डेटा प्रोसेसिंग करती हैं या दूसरे बैंकों/संस्थानों को डेटा भेजती हैं।

बैंकों के सामने मौजूद समस्याएं

  • मेनफ़्रेम इस्तेमाल करने वाले बैंकों के सामने संभालने के लिए बहुत सी समस्याएं हैं।
  • प्रोग्रामर बूढ़े होते जा रहे हैं, और नए कर्मचारियों को स्वतंत्र रूप से काम करने लायक बनने में 2-3 साल लगते हैं।
  • दशकों पुराने प्रोग्राम मौजूद हैं, और किसी को नहीं पता कि वे क्या करते हैं।

अंतिम शब्द

  • यह देखना बेहद दिलचस्प होगा कि Nordea और दूसरे बैंक आने वाले वर्षों में कौन-सी नई तकनीकें अपनाते हैं।

Q & A

  • IBM मेनफ़्रेम COBOL प्रोग्रामिंग क्यों चुनी? क्योंकि वह कंप्यूटर के साथ काम करना चाहती थीं।
  • दिन का सबसे बुरा अनुभव क्या था? एक सहकर्मी ने महत्वपूर्ण सिस्टम मॉड्यूल में एक dot छोड़ दिया, जिससे बैंक 16 घंटे तक डाउन रहा।
  • बैंक का भविष्य कैसा होगा? उन्हें एहसास है कि मेनफ़्रेम को किसी आधुनिक चीज़ से बदलना होगा।
  • 90 के दशक में महिला प्रोग्रामर होने के नाते कौन-सी चुनौतियां थीं? कोई समस्या नहीं थी।
  • 20 साल से ज़्यादा समय तक उसी codebase पर काम करना उबाऊ हो जाता है? नए सिस्टम बनाना हमेशा मजेदार था।
  • बैंक के लिए code लिखना डरावना है? बहुत डरावना, लेकिन test environment मजबूत है, इसलिए ज्यादातर काम आसानी से हो जाता है।
  • क्या आपने कभी बैंक के लिए कोई बड़ी गलती की? 1997 में उन्होंने ऐसी गलती की जिससे retirement savings account से गैरकानूनी तरीके से पैसे निकाले जा सकते थे।
  • काम का माहौल कैसा है? निजी डेस्क से open office में जाना पड़ा, और उन्हें यह बिल्कुल पसंद नहीं है।

GN⁺ की राय

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

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2023-12-15
Hacker News की राय

  • 2016 में मूल HN submission https://news.ycombinator.com/item?id=12096250 था
    अगर “bank programming की दुनिया हममें से अधिकतर लोगों की परिचित दुनिया से बिल्कुल अलग है” वाले विषय पर और पढ़ना चाहते हैं, तो An oral history of Bank Python भी अच्छा है: https://calpaterson.com/bank-python.html
    यह पहले HN पर भी आया था: https://news.ycombinator.com/item?id=29104047

    • यकीन नहीं होता कि उसे 7 साल हो चुके हैं। मैं अपनी मां का interview करना चाहता था कि वे Michigan Algorithm Decoder से mainframe program कैसे करती थीं, लेकिन आखिरकार कर नहीं पाया
      https://news.ycombinator.com/item?id=12097032

  • लोग अक्सर सोचते हैं कि “20 साल के mainframe programmer को बहुत ज्यादा salary मिलती होगी क्योंकि उम्र बहुत मूल्यवान है”, लेकिन हकीकत में pay आम तौर पर औसत या औसत से भी कम होता है, जिससे talent pipeline problem बनती है
    असली कीमती चीज़ “COBOL आता है” जैसी skill अपने-आप में नहीं है, बल्कि COBOL में जमा बहुत बड़ा business logic समझने वाली organizational knowledge है। कोई औसत developer भी COBOL सीख सकता है, लेकिन retired COBOL programmer अगर सालाना 5 लाख डॉलर के contract पर लौटता है, तो वह COBOL की वजह से नहीं, बल्कि जमा हुई institutional knowledge की वजह से होता है
    अगर banks और institutions ने युवा mainframe programmers को वाकई ऊंचा वेतन दिया होता, तो आज की demographic problem इतनी गंभीर नहीं होती

    • grad school में मेरी मुलाकात ऐसे ही हालात वाले एक व्यक्ति से हुई थी। वह bank में काम करता था, financial crisis के समय निकाल दिया गया, और bank पुराने system को Java जैसी चीज़ में migrate करने की कोशिश कर रहा था
      उन्हें लगा project लगभग खत्म है, rewrite team COBOL से काफी परिचित हो चुकी है इसलिए बाकी काम उसके बिना हो जाएगा, लेकिन असल में COBOL समझ लेने के बावजूद उनकी institutional knowledge की सख्त जरूरत थी। आखिरकार transition पूरा होने तक वह बेहद ऊंचे consulting rate पर part-time वापस आया, और उसी दौरान grad school करते हुए अपनी capabilities बढ़ाईं
    • मैंने एक बड़ी insurance company में COBOL core systems पर काम किया था और पूरी तरह सहमत हूं। कंपनी COBOL knowledge के लिए पैसे नहीं दे रही थी, बल्कि उन लोगों के लिए दे रही थी जो code के अंदर की undocumented quirks और traps जानते थे
      कोई ठीक-ठाक programmer COBOL program पढ़कर follow कर सकता है। लेकिन यह नहीं जानता कि 10-K filing के लिए data extraction के दौरान critical export क्यों fail हो जाता है। वजह यह थी कि किसी ने मान लिया था कि किसी खास record count 3000 से ज्यादा नहीं होगा, और उससे ऊपर जाते ही बस error देने के लिए hardcode कर दिया था
    • शुरुआती नौकरी में मैंने bank/insurance mainframe का काम किया था, और work environment dress code जैसी छोटी बातों से लेकर बेहद पुराने legacy codebase जैसी मुश्किल चीजों तक काफी खराब था। अगर पैसे अच्छे मिलते तो सह लेता, लेकिन ऐसा भी नहीं था
      असल में मुझे अपनी पिछली नौकरी, physical cable infrastructure installation यानी fiber optic और copper Ethernet लगाने, से भी काफी कम मिल रहा था, और मैंने वह काम सिर्फ इसलिए चुना था कि office में air conditioning थी। यह ऐसा काम नहीं था जिसे मैं career बनाना चाहता
      cloud provider में customer-facing phone support करने वाले mid-level Windows system administrator के रूप में मैंने bank/insurance company में junior mainframe role की तुलना में करीब 30% ज्यादा कमाया। दुर्लभ skill और high-value industry होने के बावजूद mainframe work को बहुत कम compensation मिला, और उस company में mainframe developers को हर career level पर developers में सबसे कम pay मिलता था। सही compensation सिर्फ उस independent contractor को मिल रहा था जिसने retirement से पहले वहां 30 साल काम किया था
    • मेरे पास COBOL experience है, mainframe पर भी किया है, और फिर से करने को तैयार हूं। COBOL programmer standards से मैं अभी भी young हूं, इसलिए कोई मुझे 20 साल और काम में ला सकता है
      लेकिन ऐसे roles की wages दूसरी technologies से मिलने वाले compensation के मुकाबले दयनीय हैं, और आधुनिक जीवन ज्यादा salary के पीछे जाने का काफी दबाव डालता है
    • सच में ऐसे case होते हैं। मैंने US-headquartered multinational bank में काम किया था, जहां headquarters team ने नए computer science graduates को लाने के लिए एक चमकदार program बनाया था
      यह program industry entry-level jobs का “fair” market rate देता था, और पहले साल 2–3 teams या departments का experience कराता था। अंत में अगर candidate को company अभी भी पसंद हो, तो वह permanent role के लिए team चुन सकता था, लेकिन salary increase नहीं होता था, और उस समय तक जो लोग जल्दी perform नहीं कर पाए थे वे पहले ही filter हो चुके होते थे
      company के लिए नतीजा शानदार था। वे नए colleagues से ज्यादा COBOL में सक्षम young programmers को सालाना 60–70 हजार डॉलर में रख सकते थे, जबकि senior या long-tenured colleagues को cases के हिसाब से 2–4 लाख डॉलर मिलते थे

  • मेरी दादी punched cards से programming करती थीं, लेकिन कौन सा hardware था मुझे नहीं पता, और अब पूछने के लिए बहुत देर हो चुकी है। मेरे पिता ने Soviet mainframes पर Fortran और COBOL बहुत किया, और बाद में US में Y2K पर भी काफी काम किया
    उनमें सबसे cool चीज़ वह Fortran program printout है जिसे पिता ने अपनी पुरानी mountain photo के 64mm large-format film को लपेटने के लिए तीन टुकड़ों में फाड़कर इस्तेमाल किया था। शायद वह Minsk-32 mainframe से निकला था, program का नाम MATR1 है, matrix manipulation करता है और comments में terrain का जिक्र है। अब मैंने उसे अपने workbench के पास wall पर frame करके लगाया है
    मैं भी जिंदगी भर कई languages में coding करता रहा हूं, और अब मेरा teenage बच्चा high school में Java और Python करते हुए coding में interest दिखा रहा है। 4th-generation programmer बनने की ओर

    • यह तो एक film idea जैसा है जिसमें वही codebase पीढ़ियों तक आगे बढ़ता है। Title Legacy Code अच्छा रहेगा

  • तकनीकी नज़रिए से अगर यह कहना सही है कि यह बैंक की सबसे अहम जगह है, तो Nordea के स्वीडन और Nordic बाज़ारों में market share को देखते हुए, अगर वह टीम गायब हो जाए तो स्वीडन—और शायद Nordic अर्थव्यवस्था तक—हिल सकती है। तब EU पर भी काफ़ी असर पड़ेगा लगता है।
    यह लेख पढ़ने के बाद से मैं लगातार सोचता रहा हूँ कि ऐसे बैंकों को चलाए रखने वाले COBOL प्रोग्रामर दुनिया की कई अर्थव्यवस्थाओं में बेहद कम आंके गए bus factor तो नहीं हैं। यह भी जानना चाहूँगा कि ऐसी स्थिति के लिए backup plan क्या है।
    [0] https://en.wikipedia.org/wiki/Nordea

    • सोचने लगा कि क्या APL प्रोग्रामरों की भी ऐसी ही स्थिति होगी। मेरी जानकारी में काफ़ी बड़ी कंपनियाँ APL इस्तेमाल करती हैं।
    • ऐसी स्थिति का backup plan बदनाम तौर पर कई हफ्तों तक काम बंद रहना भी हो सकता है: https://en.wikipedia.org/wiki/TSB_Bank_(United_Kingdom)#Migration_to_the_Sabadell_Proteo_banking_platform
      मुझे लगता है उस तबाही में institutional knowledge का खोना एक बड़ा कारण रहा होगा।
    • एक ऐसे प्रोग्रामर के रूप में जिसे बस ने टक्कर मारी है—वह भी उसी बस ने जिसमें मैं पश्चिमी ग्रीस के आख़िरी स्टेशन तक 5 घंटे सफ़र करके गया था—कहूँ तो कार से टकराकर मरने का जोखिम कहीं ज़्यादा है।
      पैदल चलने वालों और साइकिल चलाने वालों के लिए ज़्यादा ख़तरनाक SUV की बढ़ती बिक्री को जोड़ दें, तो यह बात उलटी हैरान कर सकती है कि बैंक मृत प्रोग्रामरों की वजह से नहीं, बल्कि खराब accounting और fraud की वजह से गिरते हैं।

  • “मेरी अपनी desk थी, लेकिन अब ऐसी open space में शिफ्ट कर दिया गया है जहाँ कोई भी सीट चुनकर बैठना होता है, और मुझे यह सच में नापसंद है” वाला हिस्सा, mainframe पर काम न किया हो तब भी, अजीब तरह से बहुत relate होता है।

    • मैं भी अपनी personal desk को कहीं ज़्यादा पसंद करता हूँ। कोई व्यक्ति अपने स्वाद और पसंद के हिसाब से अपना environment सेट करे, यह बहुत स्वाभाविक है; समझ नहीं आता कि कुछ office designers इसे ध्यान में क्यों नहीं रखते।
    • सोचता हूँ कि क्या हमारे यहाँ की तरह ज़्यादातर offices में भी “flexible seating” कहा जाता है, लेकिन असल में सबकी अपनी जगह होती है, लोग office आते ही हमेशा उसी desk पर बैठते हैं, और आम तौर पर एक-दूसरे की इस बात का सम्मान करते हैं।
      chair, monitor की position और brightness, desk की height आदि अपने हिसाब से सेट होती हैं, इसलिए hotdesking का concept ही हास्यास्पद हो जाता है। बेहतर हो कि इसे आधिकारिक तौर पर छोड़ ही दिया जाए।

  • financial services में system integration consultant के रूप में काम करते समय मुझे ऐसे core banking systems के साथ बहुत integration करनी पड़ती थी।
    आम तौर पर अगर बिल्कुल नया interface negotiate किया जाए तो technical, business और compliance से जुड़ी friction इतनी बढ़ जाती थी कि project आसानी से 1–2 साल या उससे ज़्यादा खिसक सकता था, इसलिए हम पिछले projects के existing integration points को reuse करने की कोशिश करते थे।
    integration ज़्यादातर रात की batch processing के लिए शाम के किसी तय समय से पहले structured documents पहुंचाने के तरीके से होती थी। offset-based data documents में future updates और उपयोग के लिए अभी assign न किए गए areas design में ही रखे जाते हैं, और जब नई जानकारी चाहिए होती है तो यह negotiate किया जाता है कि उनमें से कौन से bytes इस्तेमाल किए जा सकते हैं।
    data extraction की तरफ़ कभी-कभी ज़्यादा “modern” API ढूँढी जाती है, लेकिन बारीक REST जैसी चीज़ों की बहुत उम्मीद नहीं करनी चाहिए। महंगे नए development से बचने का रास्ता खोजने के लिए regulators और compliance वालों के साथ meetings अक्सर होती थीं।
    साथ में यह भी कि compliance वाले कई बार IT से कहीं ज़्यादा practical और solution-oriented होते थे। नियमों की भाषा का मतलब यह ज़रूरी नहीं कि उसे सबसे restrictive तरीके से शाब्दिक रूप से ही पढ़ा जाए—यह बात अपनी team को समझाना कई बार compliance वालों से सहमति बनाने से भी कठिन होता था।
    अगर आप कल्पना करें कि ऐसी integration layer दशकों में सैकड़ों projects के जरिए जमा हुई है, तो पहली बार अंदाज़ा होगा कि core system replacement इतना मुश्किल क्यों है।

  • मेरी सास ने पूरी ज़िंदगी एक insurance company के IT department में काम किया। उन्होंने बहुत programming नहीं की, लेकिन समय के साथ domain knowledge का स्रोत बन गईं।
    पुराने किस्से बहुत हैं। ठीक-ठाक computer systems से पहले स्वाभाविक रूप से सब कुछ physical documents में stored होता था, और college graduation के बाद उनका पहला project head office की नई strategy के अनुसार branches के file system को reorganize करने के लिए satellite offices में घूमना था।
    जब team सचमुच सारे documents निकालकर उन पर नए labels लगाकर वापस रख रही थी, तब उस branch का काम रुक जाता था, और पूरा project एक साल से ज़्यादा चला। इससे मेरे अपने काम को देखने का नज़रिया कुछ बदल गया।

    • उस समय banks कागज़ की सीमाओं को कितना धकेल रहे थे, यह सोचें तो modern bank की complexity की कल्पना करना मुश्किल है। finance के बारे में पर्याप्त नहीं जानता, इसलिए यह भी समझ नहीं आता कि इसकी समझ कहाँ से शुरू करूँ।

  • काश दादी को dementia होने से पहले उनसे और ज़्यादा बातें कर ली होतीं। मुझे पता था कि वे mathematician और programmer थीं, लेकिन कुछ साल पहले थोड़ी बातचीत में उन्होंने बताया था कि सोवियत संघ में वे satellite orbits calculate करने का काम करती थीं।
    कम से कम उम्मीद है कि वे satellites ही थे।

    • मेरी भी मिलती-जुलती स्थिति है। मेरी माँ AEGIS system के लिए software simulation पर काम करती थीं। 1980s में एक अश्वेत महिला के लिए यह आम बात नहीं थी।
      उन्होंने 20 साल की उम्र में 3 साल में math degree पूरी की, और 1970s में punch cards से computers program किए।
      अब वे जूतों के फीते भी भरोसेमंद ढंग से नहीं बाँध पातीं। बहुत देर होने से पहले अपने प्रियजनों की उपलब्धियों और जीवन-कथाओं को record कर लें।
    • अगर आपने कभी ऐसा करने के बारे में सोचा है, तो ज़रूर करें। शुरुआत कैसे करें, यह सोच रहे हों तो StoryCorps app की सलाह दूँगा।
      इस्तेमाल में आसान है, पहले से बने बहुत सारे सवाल हैं, और आप अपने सवाल भी बना सकते हैं। सीधे phone में recording कर सकते हैं, और चाहें तो interview को U.S. Library of Congress में upload भी कर सकते हैं।
      https://storycorps.org/participate/storycorps-app/
    • दोनों भी हो सकते थे: https://en.wikipedia.org/wiki/Fractional_Orbital_Bombardment_System#Development_history_and_deployment

  • दादी इस साल 95 वर्ष की हो गईं। वे अभी भी पूर्व Soviet क्षेत्र की एक research institute में रोज़ जाती हैं और Fortran और Maple में numerical simulations लिखती हैं।
    उनके colleagues अब भी retire नहीं करना चाहते, और दादी भी हर साल retirement टाल देती हैं। उनकी numerical analysis और mathematics की knowledge शानदार है; मुझे उन पर सच में गर्व है।

  • पहली programming job एक transportation company में थी, जहाँ कई programmers 15–20 साल या उससे ज़्यादा समय से काम कर रहे थे, और उनमें से काफी लोग business चलाने वाले COBOL को मुख्य रूप से maintain करते थे
    उन senior programmers में कई महिलाएँ थीं, और senior group में तो ऐसा लगता था कि उनका हिस्सा 50% से भी ज़्यादा है। दुख की बात यह थी कि young programmers में भी अब भी काफी महिलाएँ थीं, लेकिन कुल मिलाकर वे ज़्यादातर पुरुष थे
    वह company मुख्य रूप से local engineering colleges से hiring करती थी, इसलिए समय के साथ software engineering major में आने वाली महिलाओं की संख्या कैसे घटी, यह दिखाने वाला एक दिलचस्प उदाहरण जैसा लगा

    • मुझे याद है कि सुना था, पुराने समय में computer programming को typing या secretarial work जैसा माना जाता था, इसलिए शुरुआत में यह मुख्य रूप से महिलाओं को आकर्षित करता था