आईबीएम सिस्टम i (उर्फ एएस / 400) - हमने ग्रीन स्क्रीन एप्लिकेशन ऑटो-टेस्ट कैसे किया

नमस्ते! मेरा नाम एंटोन वोरोब्योव है, मैं केंद्रीकृत बैंकिंग प्रणाली के लिए अनुप्रयोगों के विकास के लिए अल्फा बैंक में जिम्मेदार हूं।

इस पोस्ट में, मैं आपको बताऊंगा कि हरे रंग के स्क्रीन अनुप्रयोग क्या हैं, उनकी आवश्यकता क्यों है और हमने इसके लिए अपना समाधान लिखकर उनके लिए ऑटोटैस्ट कैसे किया, जिसने हमें 11 बार ऑटोटेस्ट में तेजी लाने की अनुमति दी।



एएस / 400 प्लेटफार्म (एप्लीकेशन सिस्टम / 400) का जन्म 1988 में हुआ था। इस प्लेटफ़ॉर्म के लिए पहला OS OS / 400 है, जिसे बाद में i5 / OS का नाम दिया गया और बाद में IBM i को भी। बहुत पहले नहीं, उसने अपना तीसवां जन्मदिन मनाया।

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

IMHO, यह OS आपको इस बारे में पागल बना सकता है कि C ++ कोड लिखने के लिए सामान्य दृष्टिकोण इस पर अप्रभावी हैं (दसियों बार CPU नुकसान), कि पाठ्यपुस्तकों में प्रदर्शित कुछ एंटीपैटर्न प्रभावी कोड का सबसे अच्छा अभ्यास हैं, और लेखन की तारीख के साथ स्रोत 1978 के लिए न केवल समस्याओं के बिना इकट्ठा, बल्कि डिजाइन के रूप में भी काम करते हैं! यह सब हमें सॉफ्टवेयर के विकास के लिए आधुनिक दृष्टिकोण पर एक नया रूप देता है।

परिचय

विकास के तहत सॉफ्टवेयर की गुणवत्ता में सुधार का मुद्दा प्रत्येक विकास टीम के दिमाग को उत्तेजित करता है। हमारी क्रेडिट टीमों में से एक, जिसका कार्य मिस्स इक्वेशन ऑटोमेटेड बैंकिंग सिस्टम के लिए मॉड्यूल के पिछले हिस्से को विकसित करना और विकसित करना है, इस पल को भी नहीं दरकिनार किया है। इस ABS की ख़ासियत यह है कि:

• ABS के पहले संस्करणों ने पूर्ववर्ती AS / 400 - IBM System / 38 प्लेटफार्म (1978 में प्रदर्शित) के तहत CPF OS - "कंट्रोल प्रोग्राम फैसिलिटी" के तहत काम किया;
• यह बीसवीं शताब्दी के 70 के दशक के बाद से विकसित किया गया है, और आप अपने जन्म (बहुत पुराने कोड) से पहले लिखे गए कोड पर आ सकते हैं;
• एबीएस के साथ काम करने की विशेषताएं आईबीएम i के साथ घनिष्ठ एकीकरण के कारण हैं, और बाद की पिछड़ी हुई अनुकूलता के कारण, ऐसा लगता है कि आप महान पिरामिड की खुदाई में पुरातत्वविद् के रूप में काम कर रहे हैं।

आईबीएम मैं (लोगो)

इस ABS (ABS विकल्प) के लिए अनुप्रयोगों का विकास Misys ITP इंटीग्रेटर के तकनीकी पैकेज के मानक के अनुसार किया जाता है, जो यह निर्धारित करता है कि विकल्प अंतिम उपयोगकर्ता के साथ टर्मिनल इंटरैक्शन के लिए एक इंटरैक्टिव प्रोग्राम से मिलकर होना चाहिए और पृष्ठभूमि निष्पादन के लिए स्थापित इंटरफ़ेस का उपयोग करके एपीआई को लागू करना चाहिए। ।

आईबीएम आई ऑपरेटिंग सिस्टम के तहत विकसित ऐसे इंटरेक्टिव प्रोग्राम को ऐतिहासिक रूप से ग्रीन स्क्रीन एप्लिकेशन कहा जाता है और यह एकमात्र यूआई है जिसके साथ इस एबीएस के उपयोगकर्ता सहभागिता करते हैं।

ग्रीन स्क्रीन एप्लिकेशन क्या है?

सरल उत्तर एक ऐसा अनुप्रयोग है जो इस तरह दिखता है:



या तो :

क्यों हरी स्क्रीन क्षुधा?

ऐतिहासिक रूप से, एएस / 400 परिवार और अन्य आईबीएम मेनफ्रेम की निम्न और मध्य-श्रेणी प्रणालियों पर चलने वाले एकमात्र इंटरैक्टिव अनुप्रयोग जो आपको किसी भी उपयोगकर्ता इनपुट का अनुरोध करने की अनुमति देते हैं, हरे रंग के स्क्रीन अनुप्रयोग हैं। स्थापना, प्रशासन, कॉन्फ़िगरेशन और विकास आईबीएम i ऑपरेटिंग सिस्टम (और इसके पूर्ववर्ती i5 / OS और AS400) पर किए गए थे (और अभी भी कहीं किए जा रहे हैं) विशेष रूप से हरी स्क्रीन अनुप्रयोगों का उपयोग कर रहे हैं।

ग्रीन स्क्रीन एप्लिकेशन इमेज के दो आकार हैं - 24x80 और 27x132 अक्षर और 16 संभावित रंग। इस पैमाने के भीतर, इस ऑपरेटिंग सिस्टम के डेवलपर्स और उपयोगकर्ताओं के अधिकांश कार्य किए जाते हैं।

इस तरह के स्क्रीन साइज "वर्कस्टेशंस" के विकास का परिणाम है जो बिजनेस कंप्यूटर आईबीएम सिस्टम / 32, सिस्टम / 34, सिस्टम / 36 और सिस्टम / 38 के लो-एंड और मिड-रेंज सेगमेंट से AS400 पूर्वजों से जुड़े थे। इन वर्कस्टेशनों को टर्मिनलों कहा जाता था और एक धातु के मामले में एक कीबोर्ड के साथ एक स्क्रीन और एक लाइट पेन के रूप में अतिरिक्त उपकरण शामिल थे। प्रारंभ में, केवल दो स्क्रीन रंगों का समर्थन किया गया था - हरा और चमकदार हरा, यही वजह है कि स्थापित वाक्यांश "ग्रीन स्क्रीन एप्लिकेशन" (अंग्रेजी साहित्य में ग्रीन स्क्रीन एप्लिकेशन) चला गया। 1970 के दशक में, समर्थित रंगों की संख्या बढ़कर 16 हो गई।


5251 डिस्प्ले स्टेशन मॉडल 11

सबसे आम टर्मिनल विकल्प 5251 डिस्प्ले स्टेशन मॉडल 1 (स्क्रीन पर 960 वर्ण) और मॉडल 11 (स्क्रीन पर 1920 वर्ण) आयाम चौड़ाई / गहराई / ऊंचाई क्रमशः 530/400/400 मिमी के बराबर, और वजन 34 किलो था। मॉडल 1 का स्क्रीन रिज़ॉल्यूशन 12x80, मॉडल 11 - 24x80 था। टर्मिनल सीधे मेजबान सिस्टम से जुड़ा था।

5251 डिस्प्ले स्टेशन मॉडल 2 (स्क्रीन पर 960 वर्ण) और मॉडल 12 (स्क्रीन पर 1920 वर्ण) 45 आयाम और 45 किलो वजन के साथ भी काफी सामान्य थे। वे मॉडल 1 (या 11) टर्मिनलों के साथ डेस्कटॉप प्रिंटर या एक अलग फ़्लोर प्रिंटर के रूप में सस्ते क्लाइंट से होस्ट मशीन में स्वयं के माध्यम से अपस्ट्रीम कनेक्शन "फॉरवर्ड" करने की संभावना से मॉडल 1 और मॉडल 11 से प्रतिष्ठित हैं। इस प्रकार, मॉडल 2 और 12 ने हब के रूप में काम किया, मेजबान मशीन से सीधे कनेक्शन की आवश्यकता वाले उपकरणों से मेजबान के लिए कनेक्शन का अनुमान लगाया, और काफी अधिक लागत।

5252 दोहरी प्रदर्शन स्टेशन श्रृंखला के टर्मिनल भी आधुनिक आम आदमी के लिए असामान्य प्रतीत होंगे।


आईबीएम सिस्टम / 38 उपकरण और कार्यक्रम विवरणिका से प्रचारक छवि (5252 दोहरी प्रदर्शन स्टेशन)

एक प्रिंटर से जुड़े एक टर्मिनल किट की कीमत कई हजार अमेरिकी डॉलर तक पहुंच सकती है।

टर्मिनलों को ट्विनएक्सियल केबल के माध्यम से होस्ट मशीन से आधा द्वैध मोड में एक बस टोपोलॉजी के साथ 1 एमबीपीएस तक की ट्रांसमिशन गति के साथ जोड़ा गया था। ट्विनैक्सल द्वारा समर्थित टर्मिनलों की अधिकतम संख्या 6 टर्मिनलों तक है, और मेजबान से सबसे दूरस्थ टर्मिनल 1500 मीटर से अधिक की दूरी पर स्थित होना चाहिए।

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

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


ISA बस के लिए 5250 एडाप्टर (निर्माता अज्ञात)


ब्लैकबॉक्स 5250 एडाप्टर कार्ड (PC470C, PC471C, PC472C, PC473C, PC478C)

MS-DOS और MS Windows के लिए एमुलेटर, IBM और तृतीय-पक्ष निर्माताओं से OpenSource कार्यान्वयन (उदाहरण के लिए, tn5250j.sourceforge.net सहित) से दिखाई देते हैं। 90 के दशक के मध्य में, TCP / IP स्टैक मध्य दुनिया में आता है। -प्रणाली और लो-एंड बिजनेस मशीनें। नए प्रोटोकॉल के माध्यम से होस्ट एक्सेस का समर्थन करने के लिए, आईबीएम 5250 श्रृंखला टर्मिनल एमुलेटर विकसित कर रहा है।

एक होस्ट प्रोटोकॉल बनाने के लिए, IBM विकसित हो रहा है
टेलनेट प्रोटोकॉल एक्सटेंशन (RFC 854, RFC 855, RFC 860, RFC 885, RFC 1091, RFC 1205, RFC 1572, RFC 2877), को सामूहिक रूप से Telnet5250 (TN5250) कहा जाता है, जो धाराओं को प्राप्त करने और संचारित करने की प्रक्रिया का वर्णन करता है। 5250 डेटा स्ट्रीम (5250 डेटा स्ट्रीम) मानक टेलनेट प्रोटोकॉल पर।


आईबीएम क्लाइंट एक्सेस / 400 विंडोज 3.1 इंस्टॉलर के लिए

आईबीएम 5250 के बारे में क्या खास है?

आईबीएम 5250 टर्मिनलों की एक विशेषता (और, तदनुसार, TN5250 प्रोटोकॉल) इसकी ब्लॉक ओरिएंटेशन है, सामान्य * निक्स टर्मिनलों के विपरीत, जो प्रतीक-उन्मुख हैं । इसका मतलब यह है कि 5250 डेटा प्रवाह जिसके द्वारा होस्ट टर्मिनल के साथ संचार करता है, डेटा ब्लॉक द्वारा प्रेषित होता है, और इसमें एक अलग प्रतीक बिना प्रेषित ब्लॉक के संदर्भ में कोई मतलब नहीं है।

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


IBM i होस्ट RZKH.de (pub400.com) के लिए लॉगिन स्क्रीन

इसके अलावा, टर्मिनल एमुलेटर का कार्य मशीन से डेटा ब्लॉक की व्याख्या करना और उपयोगकर्ता के लिए इनपुट स्क्रीन बनाना है, जहां उसे किसी भी जानकारी को अनुमत क्षेत्रों में प्रवेश करने का अवसर दिया जाता है। साथ ही, टर्मिनल एमुलेटर के कार्यों में उपयोगकर्ता क्रियाओं की प्रतिक्रिया शामिल है। F1-F24 कीज़ (F13-F24 को SHIFT + Fx के माध्यम से सिम्युलेटेड किया गया है), एंटर, होम, एंड, पेजअप, पेजड्न और कुछ अन्य विशेष कुंजी जो आधुनिक कीबोर्ड पर उपलब्ध नहीं हैं, को होस्ट कीज़ माना जाता है। इसका मतलब यह है कि इस कुंजी को दबाकर, इनपुट फ़ील्ड से जानकारी के साथ एक स्ट्रीम बफर और स्क्रीन पर कर्सर की स्थिति, जो पहले टर्मिनल एमुलेटर से भरी हुई थी, प्रसंस्करण के लिए मेजबान को भेजी जाएगी।


WIreshark 5250 pub400.com पर डेटा स्ट्रीम लॉगिन प्रयास डंप

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

आखिर यहां ऑटोटेटिंग क्यों है

हमने हरे रंग के स्क्रीन अनुप्रयोगों के मैनुअल परीक्षण को स्वचालित करने के बारे में सोचा था जब हमें एक विकसित मॉड्यूल के सैकड़ों स्क्रीन का परीक्षण करने की आवश्यकता का सामना करना पड़ा था, जहां एक स्क्रीन पर अस्सी से अधिक विभिन्न व्यावसायिक जांच (सत्यापन) हो सकते थे।

मालिकाना UIPath समाधान को छोड़कर, ग्रीन स्क्रीन ऑटो-परीक्षण उपकरण के 2017 के लिए टीम की विशेष पीड़ा लगभग पूर्ण अनुपस्थिति थी। आज भी कई समान समाधान नहीं हैं, लेखक हेल्पसिस्टम से ऑटोमेट के बारे में जानता है और ब्लेज़मीटर के लिए जेमेटर एक्सटेंशन (मुझे अन्य समान उत्पादों के बारे में जानकर खुशी होगी)।

समस्या पर पहला शोध

बैंक में कार्यस्थलों पर स्थापित TN5250 टर्मिनल का मानक एमुलेटर विंडोज़ 6.0 (PCOMM 6.0) के लिए आईबीएम पर्सनल कम्युनिकेशंस है । सहकर्मियों ने पाया कि इस उत्पाद के पास विविध एपीआई के रूप में अपने प्रबंधन को स्वचालित करने का नियमित साधन है:

1. उच्च-स्तरीय भाषा अनुप्रयोग प्रोग्राम इंटरफ़ेस (HLLAPI);
2. संवर्धित HLLAPI;
3. Windows HLLAPI
4. होस्ट एक्सेस क्लाइंट लाइब्रेरी (HACL)।

पहले तीन इंटरफेस सबसे पुराने हैं और डॉस और विंडोज के 16-बिट संस्करणों के बाद से समर्थित हैं। निम्नलिखित प्रोटोटाइप के अनुसार एकल फ़ंक्शन को कॉल करके EHLLAPI इंटरफ़ेस पर काम किया जाता है:

long hllapi (LPWORD, LPSTR, LPWORD, LPWORD); 

जहां पहला पैरामीटर कार्य के संख्यात्मक संख्या के लिए एक संकेतक है, जिसे निष्पादित किया जा रहा है, अन्य दो इसके तर्क संदर्भ हैं जो फ़ंक्शन को बुलाया जा रहा है, और अंतिम फ़ंक्शन का परिणाम है। अर्थात्, कनेक्शन स्थिति 'ए' का अनुरोध करने के लिए (एमुलेटर में सत्र 'ए' से 'जेड' तक की सीमा के लैटिन अक्षर के साथ गिने जाते हैं), आपको निम्न कोड (आईबीएम प्रलेखन से लिया गया) चलाना चाहिए:

  #include "hapi_c.h" struct HLDQuerySessionStatus QueryData; int Func, Len, Rc; long Rc; memset(QueryData, 0, sizeof(QueryData)); // Init buffer QueryData.qsst_shortname = 'A'; // Session to query Func = HA_QUERY_SESSION_STATUS; // Function number Len = sizeof(QueryData); // Len of buffer Rc = 0; // Unused on input hllapi(&Func, (char *)&QueryData, &Len, &Rc); // Call EHLLAPI if (Rc != 0) { // Check return code // ...Error handling } 

इस तरह से कॉल करने के लिए उपलब्ध कार्यों की संख्या लगभग 60 है।

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

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


HACL एमुलेटर क्लास लाइब्रेरी क्लास पदानुक्रम (C ++)

C ++, Java, LotusScript और Windows के लिए COM ऑटोमेशन सर्वर (विजुअल बेसिक और .NET के लिए सुविधाजनक) के लिए HACL कार्यान्वयन हैं।

पहला प्रोटोटाइप

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

सहकर्मी जो पहले HACL इंटरफेस का इस्तेमाल करते थे, उन्होंने दावा किया (और StackOverflow पर एक खोज की पुष्टि की) कि COM ऑब्जेक्ट में स्थिरता की समस्या थी और एक निश्चित संख्या में कमांड निष्पादित होने के बाद लटका सकते हैं। केवल स्वचालन सर्वर प्रक्रिया को पुनरारंभ करने से मदद मिली। जावा संस्करण के एक त्वरित विश्लेषण से पता चला है कि जेएनआई के माध्यम से C ++ इंटरफ़ेस पर रैपर का उपयोग किया जाता है। इसलिए, चुनाव C ++ इंटरफ़ेस पर गिर गया। संबंधित हेडर फ़ाइलें और .lib फाइलें विंडोज के लिए व्यक्तिगत संचार की स्थापना निर्देशिका में उपलब्ध थीं।

पहला प्रोटोटाइप Qt5 पर आधारित था, जहाँ QtScript के माध्यम से जावास्क्रिप्ट कोड निष्पादित करना संभव था। निष्पादन योग्य स्क्रिप्ट के वातावरण में, एक वस्तु को कम संख्या में विधियों के साथ पंजीकृत किया गया था जो टर्मिनल एमुलेटर में कमांड निष्पादित करने की अनुमति देता था जैसे कि उन्हें किसी व्यक्ति द्वारा निष्पादित किया जा रहा था (एक फ़ील्ड में प्रवेश, मेजबान कुंजी दबाकर, स्क्रीन पर दिखाई देने के लिए एक लाइन का इंतजार करना)। हमने लाइव "डेमो" का प्रदर्शन किया, जहां हमने एबीएस इक्वेशन से एक हरे रंग की स्क्रीन एप्लिकेशन को लॉन्च करने के लिए एक उपयोगकर्ता के मामले को लिपिबद्ध किया, जिसमें एप्लिकेशन को फ़ील्ड के गलत इनपुट की प्रतिक्रिया का परीक्षण किया गया था। प्रदर्शन से पता चला कि प्रोटोटाइप सफल था और हम आगे बढ़ सकते हैं।

एक पड़ोसी की उपस्थिति

पहले प्रोटोटाइप के प्रदर्शन के साथ, दूसरे विभाग के सहयोगियों ने रूबी + ककड़ी + क्विक3270 + रूबी मॉड्यूल ( चेज़ / टी 3270 ) का एक गुच्छा रखा। प्रस्तावित संस्करण एक रूबी मॉड्यूल का उपयोग करता है जो DN32 कम्प्यूटिंग क्विक 3270 टर्मिनल एमुलेटर के साथ अपने विशिष्ट COM ऑब्जेक्ट्स (एचएसीएल इंटरफेस के साथ असंगत) के माध्यम से संपर्क करता है। यह बीडीडी-शैली की हरी स्क्रीन ऑटो-परीक्षण अनुप्रयोगों के लिए एक पूर्ण समाधान था, जिसमें कुछ पूर्व-वर्णित कदम थे। हालांकि, प्रस्तावित समाधान में, हम निम्नलिखित द्वारा चिंतित थे:

1. हमने आईबीएम से नहीं एक तृतीय-पक्ष भुगतान किए गए एमुलेटर का उपयोग किया (सभी एमुलेटर थोड़ा अलग तरीके से काम करते हैं, लेकिन हमें बैंक में उपयोग किए जाने वाले मानक पर काम की जांच करने की आवश्यकता है, त्रुटि की कीमत अविश्वसनीय रूप से अधिक है);
2. Quick3270 के लिए ककड़ी के चरणों के कार्यान्वयन ने मशीन से प्रतिक्रिया के लिए प्रतीक्षा करने के लिए बड़ी संख्या में नींद का उपयोग किया;
3. स्वचालन इंटरफ़ेस (C ++ इंटरफ़ेस के माध्यम से प्रोटोटाइप में HACL के साथ काम करना) के माध्यम से Quick3270 का बहुत खराब प्रदर्शन बहुत अधिक गतिशील लग रहा था।

Quick3270 टर्मिनल एमुलेटर

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

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

खुद का फैसला

अपने स्वयं के समाधान के रूप में, हमने पहले प्रदर्शित किए गए प्रोटोटाइप के विकास के रूप में एक स्वचालन सर्वर बनाया। यह सर्वर RPC सर्वर (Qt5 WebSocket) के माध्यम से उपभोक्ताओं से बातचीत को स्वचालित करने के लिए कमांड निष्पादित करता है। यह विंडोज के लिए व्यक्तिगत संचार के साथ बातचीत करता है, जो कॉर्पोरेट विंडोज ऑपरेटिंग सिस्टम छवि का हिस्सा है, और आपको इसकी अनुमति देता है:

• टर्मिनल एमुलेटर सत्र शुरू / रोकें;
• प्रदर्शन स्क्रीन स्क्रीनिंग ग्रीन स्क्रीन;
• स्क्रीन पर खोज इनपुट फ़ील्ड;
• कर्सर को नियंत्रित करें और कीस्ट्रोक्स (मेजबान सहित) का अनुकरण करें;
• और अन्य

स्वचालन सर्वर प्रारंभ करें

हालांकि, एचएसीएल एपीआई के सभी फायदों के लिए, इसमें एक खामी है - यह नहीं पता है कि मैं डीबीएमएस के लिए ओएस में निर्मित डीबी 2 के साथ कैसे काम करता हूं और ऐसी कमांड निष्पादित करने की अनुमति नहीं देता है जो एक नकली वातावरण बनाने के लिए महत्वपूर्ण हैं जहां एक परीक्षण स्क्रिप्ट निष्पादित की जाएगी। यदि रूबी के लिए DB2 क्लाइंट आईबीएम से मौजूद है, तो दूरस्थ कमांड और वितरित प्रोग्राम कॉल सर्वर के लिए क्लाइंट केवल जेटीओपीएन लाइब्रेरी के रूप में जावा के लिए है: जावा के लिए आईबीएम टूलबॉक्स का ओपन सोर्स संस्करण (जिसे jt400 के रूप में भी जाना जाता है। )। हमने आईबीएम पर इस समस्या के समाधान को उसी तरह की कार्यक्षमता (विशेष रूप से, विंडोज डेटा ट्रांसफर के लिए व्यक्तिगत संचार, पीसी / पीसी से आईसरीज ट्रांसफर, इत्यादि के लिए व्यक्तिगत संचार) का विश्लेषण करके "झाँका"। यह पता चला कि ये उत्पाद, उनके कार्यान्वयन से, आवेदन के संस्करण के आधार पर आईबीएम जेआरई 6 या 8 चलाते हैं, और jt400 लाइब्रेरी का उपयोग करते हैं।

स्वचालन सर्वर के लिए, हमने वही करने का फैसला किया। जेएनआई ने आईबीएम जेवीएम लॉन्च किया, जो विंडोज के लिए पर्सनल कम्युनिकेशंस के साथ काम करता है। विशेष आवरण विधियों का उपयोग करते हुए, बाहर से आने वाले आरपीसी सर्वर से कमांड को आवश्यक jt400 कार्यक्षमता में कॉल में समीप करके निष्पादित किया जाता है। चूंकि बाद में DB2 के लिए एक JDBC ड्राइवर भी शामिल है, इसलिए आईबीएम पर DBMS तक पहुंचने के लिए इसका उपयोग करने का निर्णय लिया गया था।

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

समय के साथ, समाधान को नौकरियों की बढ़ती संख्या पर लागू किया गया था। यह Quick3270 के साथ समाधान की तुलना में तेजी से काम किया। लोकप्रियता बढ़ी, जैसा कि ऑटोटेस्ट की संख्या थी। हालांकि, ऑपरेशन के दौरान, अतिरिक्त कठिनाइयां उत्पन्न हुईं:

1. समसामयिक टर्मिनल जमा देता है;
2. टर्मिनल एमुलेटर के शुरू होने से इनकार करने के कारण प्रतिगमन स्टैंड पर काम करने में असमर्थता यदि उपयोगकर्ता का डेस्कटॉप जिसके तहत एमुलेटर शुरू होता है अवरुद्ध हो जाता है या उसका आरडीपी सत्र अवरुद्ध हो जाता है;
3. विंडोज केवल;
4. उपकरण स्थापित करने, कॉन्फ़िगर करने और अद्यतन करने की एक जटिल प्रक्रिया (एमएसआई पैकेज के माध्यम से);
5. 130 ऑटोटेस्ट्स (लगभग 4000 चरणों) के लिए हमारे प्रतिगमन चक्र में 7-8 घंटे लगने लगे।

कुछ करने की जरूरत है ...

कई ऑटोटेस्ट लॉन्च के ट्रेस लॉग का विश्लेषण करके, अक्सर उपयोग किए जाने वाले चरणों के प्रदर्शन में बाधाओं की खोज करते हुए, कुल प्रतिगमन निष्पादन समय 4-5 घंटे तक कम हो गया था। लेकिन यह स्पष्ट था कि HACL इंटरफ़ेस के साथ संयोजन के रूप में स्वचालन RPC सर्वर के रूप में मिडिलवेयर परत का उपयोग करना, जिसमें "फ़्लोटिंग" त्रुटियां भी हैं जो पूरे सिस्टम की अवधि में जमा होती हैं, समाधान के प्रदर्शन को बेहतर बनाने में मदद नहीं करेगी।

दूसरी ओर, विंडोज़ के लिए आईबीएम पर्सनल कम्युनिकेशंस के विकल्प के रूप में, विक्रेता आईबीएम आई एक्सेस - क्लाइंट सॉल्यूशंस नामक एक क्रॉस-प्लेटफॉर्म समाधान प्रदान करता है ।


आईबीएम आई एक्सेस - क्लाइंट सॉल्यूशंस

कॉफी पर शनिवार और रविवार की सुबह इसकी आंतरिक संरचना के विश्लेषण से पता चला कि इसका कोड आधार IBM होस्ट ऑन-डिमांड (IBM HOD) के एक अन्य उत्पाद पर आधारित है। यह जावा 6 में विकसित आईबीएम i को एक्सेस करने के लिए एक पूर्ण विकसित समाधान है, जिसमें न केवल आईबीएम मशीनों (TN3270, TN5250, VTxxx, आदि) में उपयोग किए जाने वाले विभिन्न संचार प्रोटोकॉल का पूर्ण कार्यान्वयन है, बल्कि उच्च-स्तरीय जावा-स्विंग यूआई घटक भी हैं। एक कंस्ट्रक्टर के रूप में अपने स्वयं के टर्मिनल एमुलेटर बनाने के लिए उपयोग किया जाता है, जिसे डरावना आईबीएम प्रलेखन से इकट्ठा किया जा सकता है IBM HOD के एक अधिक विस्तृत अध्ययन से पता चला है कि UI घटक HACL इंटरफ़ेस के जावा कार्यान्वयन पर आधारित हैं, जिसका प्रलेखन खुला है। उनका व्यवहार C ++ HACL प्रलेखन से केवल मामूली अंतर के साथ मेल खाता है।


आईबीएम होस्ट ऑन डिमांड (लोगो)

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

परिणाम क्या है?

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

पहले से ही मौजूदा 180 ऑटोटेस्ट्स में 16,000 से अधिक चरणों के साथ 60 एमएस की एक सेट देरी के साथ कदमों के बीच 5 घंटे 30 मिनट के खिलाफ लगभग 30 मिनट चलने लगे, जो प्रतिगमन स्टैंड के प्रदर्शन में ग्यारह गुना वृद्धि से मेल खाती है।

परिणाम सभी अपेक्षाओं को पार कर गए। हम TN5250 प्रोटोकॉल की भौतिक सीमाओं के करीब हैं।

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

अंत तक पढ़ने के लिए धन्यवाद!
सभी सफलता!

PS दिसंबर 2018 में, अगला IBMi डेवलपर सम्मेलन आयोजित किया गया था, जिस पर इस लेख के विषय पर एक रिपोर्ट बनाई गई थी।

अब तक, हमने केवल बैंक कर्मचारियों के लिए वार्षिक सम्मेलन आयोजित किया है। 2019 से, हम अन्य कंपनियों के प्रतिभागियों को आमंत्रित करेंगे। पेशेवर और व्यक्तिगत संचार के सर्कल का विस्तार करना, भावनाओं, ज्ञान और अनुभव को साझा करना बहुत दिलचस्प है।