लेनदेन प्रसंस्करण सुविधा: Difference between revisions
No edit summary |
No edit summary |
||
| Line 69: | Line 69: | ||
|author=Anne & Lynn Wheeler}}</ref> टीपीएफ मल्टीप्रोसेसर पर चलने में सक्षम है, अर्थात उन सिस्टमों पर जिनमें से अधिक सीपीयू हैं। एलपीएआर के अंदर, सीपीयू को निर्देश स्ट्रीम या बस '''<nowiki/>'आई-स्ट्रीम'<nowiki/>''' के रूप में जाना जाता है। एक से अधिक आई-स्ट्रीम के साथ एलपीएआर पर चलने पर, टीपीएफ को '''<nowiki/>'कसकर युग्मित'<nowiki/>''' चलने वाला कहा जाता है। टीपीएफ [[सममित मल्टीप्रोसेसिंग|एसएमपी]] अवधारणाओं का पालन करता है; मेमोरी पतों के मध्य [[गैर-समान मेमोरी एक्सेस]]-आधारित भेद की कोई अवधारणा उपस्तिथ नहीं है। | |author=Anne & Lynn Wheeler}}</ref> टीपीएफ मल्टीप्रोसेसर पर चलने में सक्षम है, अर्थात उन सिस्टमों पर जिनमें से अधिक सीपीयू हैं। एलपीएआर के अंदर, सीपीयू को निर्देश स्ट्रीम या बस '''<nowiki/>'आई-स्ट्रीम'<nowiki/>''' के रूप में जाना जाता है। एक से अधिक आई-स्ट्रीम के साथ एलपीएआर पर चलने पर, टीपीएफ को '''<nowiki/>'कसकर युग्मित'<nowiki/>''' चलने वाला कहा जाता है। टीपीएफ [[सममित मल्टीप्रोसेसिंग|एसएमपी]] अवधारणाओं का पालन करता है; मेमोरी पतों के मध्य [[गैर-समान मेमोरी एक्सेस]]-आधारित भेद की कोई अवधारणा उपस्तिथ नहीं है। | ||
सीपीयू तैयार सूची की गहराई को किसी भी आने वाले लेनदेन के प्राप्त होने पर मापा जाता है, और सबसे कम मांग के साथ आई-स्ट्रीम के लिए कतारबद्ध किया जाता है, इस प्रकार उपलब्ध प्रोसेसर के मध्य निरंतर लोड संतुलन बनाए रखा जाता है। ऐसे स्थितियों में जहां '''<nowiki/>'लूज़ली कपल' | सीपीयू तैयार सूची की गहराई को किसी भी आने वाले लेनदेन के प्राप्त होने पर मापा जाता है, और सबसे कम मांग के साथ आई-स्ट्रीम के लिए कतारबद्ध किया जाता है, इस प्रकार उपलब्ध प्रोसेसर के मध्य निरंतर लोड संतुलन बनाए रखा जाता है। ऐसे स्थितियों में जहां '''<nowiki/>'लूज़ली कपल'''' कॉन्फ़िगरेशन मल्टीप्रोसेसर 'सीपीसी (सेंट्रल प्रोसेसिंग कॉम्प्लेक्स, अर्थात सिस्टम कैबिनेट में पैक की गई भौतिक मशीन) द्वारा पॉप्युलेट किया जाता है, सममित मल्टीप्रोसेसिंग '''सीपीसी''' के अंदर होती है जैसा कि यहां वर्णित है, जबकि अंतर-सीपीसी संसाधनों का साझाकरण नीचे '''<nowiki/>'लूज़ली कपल'''' के अनुसार वर्णित के अनुसार होता है। | ||
टीपीएफ आर्किटेक्चर में, सभी मेमोरी (4KB आकार के उपसर्ग क्षेत्र को छोड़कर) सभी आई-स्ट्रीम के मध्य साझा की जाती है। ऐसे उदाहरणों में जहां मेमोरी-रेजिडेंट डेटा को आई-स्ट्रीम द्वारा भिन्न रखा जाना चाहिए या होना चाहिए, प्रोग्रामर सामान्यतः आई-स्ट्रीम की संख्या के सामान्तर अनेक उपखंडों में भंडारण क्षेत्र आवंटित करता है, फिर आवंटित क्षेत्र का आधार पता लेकर वांछित आई-स्ट्रीम संबंधित क्षेत्र तक पहुंचता है, और इसमें आई-स्ट्रीम सापेक्ष संख्या के उत्पाद को प्रत्येक उपधारा के आकार से गुणा करता है। | टीपीएफ आर्किटेक्चर में, सभी मेमोरी (4KB आकार के उपसर्ग क्षेत्र को छोड़कर) सभी आई-स्ट्रीम के मध्य साझा की जाती है। ऐसे उदाहरणों में जहां मेमोरी-रेजिडेंट डेटा को आई-स्ट्रीम द्वारा भिन्न रखा जाना चाहिए या होना चाहिए, प्रोग्रामर सामान्यतः आई-स्ट्रीम की संख्या के सामान्तर अनेक उपखंडों में भंडारण क्षेत्र आवंटित करता है, फिर आवंटित क्षेत्र का आधार पता लेकर वांछित आई-स्ट्रीम संबंधित क्षेत्र तक पहुंचता है, और इसमें आई-स्ट्रीम सापेक्ष संख्या के उत्पाद को प्रत्येक उपधारा के आकार से गुणा करता है। | ||
| Line 78: | Line 78: | ||
शिथिल युग्मित प्रणाली पर डेटा रिकॉर्ड के मध्य पहुंच को क्रमबद्ध करने के लिए, [[रिकॉर्ड लॉकिंग]] के रूप में ज्ञात अभ्यास का उपयोग किया जाना चाहिए। इसका कारण यह है कि जब मेनफ्रेम प्रोसेसर रिकॉर्ड पर '''होल्ड''' प्राप्त करता है, तब तंत्र को अन्य सभी प्रोसेसर को समान होल्ड प्राप्त करने से रोकना चाहिए और अनुरोध करने वाले प्रोसेसर को सूचित करना चाहिए कि वह प्रतीक्षा कर रहे हैं। किसी भी कसकर युग्मित प्रणाली के अंदर, '''रिकॉर्ड होल्ड टेबल''' के उपयोग के माध्यम से आई-स्ट्रीम के मध्य इसे प्रबंधित करना आसान है। चूँकि, जब DASD नियंत्रण इकाई में TPF प्रोसेसर से लॉक प्राप्त होता है, तब बाहरी प्रक्रिया का उपयोग किया जाना चाहिए। ऐतिहासिक रूप से, रिकॉर्ड लॉकिंग डीएएसडी नियंत्रण इकाई में एलएलएफ (सीमित लॉकिंग सुविधा) और पश्चात् में ईएलएलएफ (विस्तारित) नामक [[ आरपीवाईए |आरपीवाईए]] के माध्यम से पूरा किया गया था। '''एलएलएफ''' और '''ईएलएलएफ''' दोनों को मल्टीपाथिंग लॉक फैसिलिटी (एमपीएलएफ) द्वारा प्रतिस्थापित किया गया था। क्लस्टर्ड (शिथिल रूप से युग्मित) z/TPF को चलाने के लिए सभी डिस्क नियंत्रण इकाइयों में या तब MPLF या वैकल्पिक लॉकिंग डिवाइस की आवश्यकता होती है [[लूस कपलिंग]] सुविधा कहा जाता है।<ref>{{cite web|url=http://publib.boulder.ibm.com/infocenter/zvm/v5r4/index.jsp?topic=/com.ibm.zvm.v54.hcpf2/hcsf9b3153.htm |title=आईबीएम नॉलेज सेंटर|website=Publib.boulder.ibm.com |date=2014-10-24 |access-date=2017-03-15}}</ref><ref>{{cite web |url=http://www-01.ibm.com/support/docview.wss?uid=swg27007957 |title=IBM z/Transaction Processing Facility Enterprise Edition V1.1 hardware requirements - United States |website=www-01.ibm.com |access-date=17 January 2022 |archive-url=https://web.archive.org/web/20121007232606/http://www-01.ibm.com/support/docview.wss?uid=swg27007957 |archive-date=7 October 2012 |url-status=dead}}</ref> | शिथिल युग्मित प्रणाली पर डेटा रिकॉर्ड के मध्य पहुंच को क्रमबद्ध करने के लिए, [[रिकॉर्ड लॉकिंग]] के रूप में ज्ञात अभ्यास का उपयोग किया जाना चाहिए। इसका कारण यह है कि जब मेनफ्रेम प्रोसेसर रिकॉर्ड पर '''होल्ड''' प्राप्त करता है, तब तंत्र को अन्य सभी प्रोसेसर को समान होल्ड प्राप्त करने से रोकना चाहिए और अनुरोध करने वाले प्रोसेसर को सूचित करना चाहिए कि वह प्रतीक्षा कर रहे हैं। किसी भी कसकर युग्मित प्रणाली के अंदर, '''रिकॉर्ड होल्ड टेबल''' के उपयोग के माध्यम से आई-स्ट्रीम के मध्य इसे प्रबंधित करना आसान है। चूँकि, जब DASD नियंत्रण इकाई में TPF प्रोसेसर से लॉक प्राप्त होता है, तब बाहरी प्रक्रिया का उपयोग किया जाना चाहिए। ऐतिहासिक रूप से, रिकॉर्ड लॉकिंग डीएएसडी नियंत्रण इकाई में एलएलएफ (सीमित लॉकिंग सुविधा) और पश्चात् में ईएलएलएफ (विस्तारित) नामक [[ आरपीवाईए |आरपीवाईए]] के माध्यम से पूरा किया गया था। '''एलएलएफ''' और '''ईएलएलएफ''' दोनों को मल्टीपाथिंग लॉक फैसिलिटी (एमपीएलएफ) द्वारा प्रतिस्थापित किया गया था। क्लस्टर्ड (शिथिल रूप से युग्मित) z/TPF को चलाने के लिए सभी डिस्क नियंत्रण इकाइयों में या तब MPLF या वैकल्पिक लॉकिंग डिवाइस की आवश्यकता होती है [[लूस कपलिंग]] सुविधा कहा जाता है।<ref>{{cite web|url=http://publib.boulder.ibm.com/infocenter/zvm/v5r4/index.jsp?topic=/com.ibm.zvm.v54.hcpf2/hcsf9b3153.htm |title=आईबीएम नॉलेज सेंटर|website=Publib.boulder.ibm.com |date=2014-10-24 |access-date=2017-03-15}}</ref><ref>{{cite web |url=http://www-01.ibm.com/support/docview.wss?uid=swg27007957 |title=IBM z/Transaction Processing Facility Enterprise Edition V1.1 hardware requirements - United States |website=www-01.ibm.com |access-date=17 January 2022 |archive-url=https://web.archive.org/web/20121007232606/http://www-01.ibm.com/support/docview.wss?uid=swg27007957 |archive-date=7 October 2012 |url-status=dead}}</ref> | ||
====प्रोसेसर साझा रिकॉर्ड==== | ====प्रोसेसर साझा रिकॉर्ड==== | ||
जिन रिकॉर्ड्स को निश्चित रूप से रिकॉर्ड लॉकिंग प्रक्रिया द्वारा प्रबंधित किया जाना चाहिए, वह हैं जो प्रोसेसर साझा किए गए हैं। टीपीएफ में, अधिकांश रिकॉर्ड एक्सेस रिकॉर्ड प्रकार और ऑर्डिनल का उपयोग करके किया जाता है। 100 रिकॉर्ड या ऑर्डिनल्स के साथ '''<nowiki/>'एफआरईडी' | जिन रिकॉर्ड्स को निश्चित रूप से रिकॉर्ड लॉकिंग प्रक्रिया द्वारा प्रबंधित किया जाना चाहिए, वह हैं जो प्रोसेसर साझा किए गए हैं। टीपीएफ में, अधिकांश रिकॉर्ड एक्सेस रिकॉर्ड प्रकार और ऑर्डिनल का उपयोग करके किया जाता है। 100 रिकॉर्ड या ऑर्डिनल्स के साथ '''<nowiki/>'एफआरईडी'''' के टीपीएफ सिस्टम में रिकॉर्ड प्रकार को देखते हुए, प्रोसेसर साझा योजना में, रिकॉर्ड प्रकार '''<nowiki/>'एफआरईडी'''' ऑर्डिनल '5' डीएएसडी पर बिल्कुल उसी फ़ाइल पते को हल करेगा - जिसके लिए रिकॉर्ड लॉकिंग तंत्र के उपयोग की आवश्यकता होगी। | ||
टीपीएफ सिस्टम पर सभी प्रोसेसर द्वारा साझा किए गए रिकॉर्ड को ही फ़ाइल पते के माध्यम से एक्सेस किया जाएगा जो ही स्थान पर हल होगा। | टीपीएफ सिस्टम पर सभी प्रोसेसर द्वारा साझा किए गए रिकॉर्ड को ही फ़ाइल पते के माध्यम से एक्सेस किया जाएगा जो ही स्थान पर हल होगा। | ||
====प्रोसेसर अद्वितीय रिकॉर्ड==== | ====प्रोसेसर अद्वितीय रिकॉर्ड==== | ||
एक प्रोसेसर अद्वितीय रिकॉर्ड वह होता है जिसे इस तरह परिभाषित किया जाता है कि शिथिल युग्मित कॉम्प्लेक्स में होने वाले प्रत्येक प्रोसेसर में 'FRED' का रिकॉर्ड प्रकार और संभवतः 100 ऑर्डिनल्स होते हैं। चूँकि, यदि किसी भी 2 या अधिक प्रोसेसर पर कोई उपयोगकर्ता उस फ़ाइल पते की जांच करता है जो रिकॉर्ड प्रकार 'FRED', क्रमिक '5' को हल करता है, तब वह देखेंगे कि भिन्न भौतिक पते का उपयोग किया गया है। | एक प्रोसेसर अद्वितीय रिकॉर्ड वह होता है जिसे इस तरह परिभाषित किया जाता है कि शिथिल युग्मित कॉम्प्लेक्स में होने वाले प्रत्येक प्रोसेसर में '''<nowiki/>'FRED'<nowiki/>''' का रिकॉर्ड प्रकार और संभवतः 100 ऑर्डिनल्स होते हैं। चूँकि, यदि किसी भी 2 या अधिक प्रोसेसर पर कोई उपयोगकर्ता उस फ़ाइल पते की जांच करता है जो रिकॉर्ड प्रकार '''<nowiki/>'FRED'<nowiki/>''', क्रमिक '''<nowiki/>'5'''' को हल करता है, तब वह देखेंगे कि भिन्न भौतिक पते का उपयोग किया गया है। | ||
==टीपीएफ विशेषताएँ== | =='''टीपीएफ विशेषताएँ'''== | ||
===टीपीएफ क्या नहीं है=== | ===टीपीएफ क्या नहीं है=== | ||
टीपीएफ सामान्य प्रयोजन वाला ऑपरेटिंग सिस्टम नहीं है। टीपीएफ की विशेष भूमिका लेनदेन इनपुट संदेशों को संसाधित करना है, फिर आउटपुट संदेशों को 1:1 के आधार पर अत्यधिक उच्च मात्रा में कम अधिकतम व्यतीत समय सीमा के साथ लौटाना है। | टीपीएफ सामान्य प्रयोजन वाला ऑपरेटिंग सिस्टम नहीं है। टीपीएफ की विशेष भूमिका लेनदेन इनपुट संदेशों को संसाधित करना है, फिर आउटपुट संदेशों को 1:1 के आधार पर अत्यधिक उच्च मात्रा में कम अधिकतम व्यतीत समय सीमा के साथ लौटाना है। | ||
टीपीएफ में कोई अंतर्निहित ग्राफिकल यूजर इंटरफेस कार्यक्षमता नहीं है, और टीपीएफ ने कभी भी प्रत्यक्ष ग्राफिकल डिस्प्ले सुविधाओं की प्रस्तुति नहीं की है: इसे होस्ट पर क्रियान्वित करना वास्तविक समय सिस्टम संसाधनों का अनावश्यक और संभावित रूप से हानिकारक मोड़ माना जाएगा। टीपीएफ का उपयोगकर्ता इंटरफ़ेस सरल टेक्स्ट डिस्प्ले टर्मिनलों के साथ कमांड-लाइन संचालित है जो ऊपर की ओर स्क्रॉल करता है, और टीपीएफ प्राइम सीआरएएस पर कोई माउस-संचालित कर्सर, विंडो या आइकन नहीं हैं<ref>{{Cite web|url=https://www.ibm.com/support/knowledgecenter/SSB23S_1.1.0.15/gtpg3/gtpg3p.html?pos=2|title=z/TPF Glossary|last=IBM Corporation|website=[[IBM]] |date=19 Apr 2018|access-date=10 May 2018}}</ref> (कंप्यूटर रूम एजेंट समूह - जिसे ऑपरेटर | टीपीएफ में कोई अंतर्निहित ग्राफिकल यूजर इंटरफेस कार्यक्षमता नहीं है, और टीपीएफ ने कभी भी प्रत्यक्ष ग्राफिकल डिस्प्ले सुविधाओं की प्रस्तुति नहीं की है: इसे होस्ट पर क्रियान्वित करना वास्तविक समय सिस्टम संसाधनों का अनावश्यक और संभावित रूप से हानिकारक मोड़ माना जाएगा। टीपीएफ का उपयोगकर्ता इंटरफ़ेस सरल टेक्स्ट डिस्प्ले टर्मिनलों के साथ कमांड-लाइन संचालित है जो ऊपर की ओर स्क्रॉल करता है, और टीपीएफ प्राइम सीआरएएस पर कोई माउस-संचालित कर्सर, विंडो या आइकन नहीं हैं<ref>{{Cite web|url=https://www.ibm.com/support/knowledgecenter/SSB23S_1.1.0.15/gtpg3/gtpg3p.html?pos=2|title=z/TPF Glossary|last=IBM Corporation|website=[[IBM]] |date=19 Apr 2018|access-date=10 May 2018}}</ref> (कंप्यूटर रूम एजेंट समूह - जिसे '''"ऑपरेटर का कंसोल"''' के रूप में सबसे अच्छा माना जाता है)। चरित्र संदेशों का उद्देश्य मानव उपयोगकर्ताओं के साथ संचार का माध्यम होना है। [[एक्स विंडो सिस्टम]] के बिना [[यूनिक्स]] के समान, सभी कार्य कमांड लाइन के उपयोग के माध्यम से पूरा किया जाता है। ऐसे अनेक उत्पाद उपलब्ध हैं जो प्राइम सीआरएएस से जुड़ते हैं और टीपीएफ ऑपरेटर को ग्राफिकल इंटरफ़ेस वेरिएबल प्रदान करते हैं, जैसे टीपीएफ ऑपरेशंस सर्वर।<ref>{{Cite web|url=https://www.ibm.com/support/knowledgecenter/SSB23S_1.1.0.15/com.ibm.tpfops.doc/kc_tos_welcome.html|title=आईबीएम टीपीएफ ऑपरेशंस सर्वर|last=IBM Corporation|website=[[IBM]] |date=19 April 2018|access-date=10 May 2018}}</ref> अंतिम उपयोगकर्ताओं के लिए ग्राफ़िकल इंटरफ़ेस, यदि वांछित हो, बाहरी सिस्टम द्वारा प्रदान किया जाना चाहिए। ऐसे सिस्टम चरित्र सामग्री पर विश्लेषण करते हैं ([[स्क्रीन स्क्रैप]] देखें) और संदेश को उसके संदर्भ के आधार पर वांछित ग्राफिकल रूप में परिवर्तित करते हैं। | ||
एक विशेष प्रयोजन ऑपरेटिंग सिस्टम होने के नाते, टीपीएफ कंपाइलर/असेंबलर, टेक्स्ट एडिटर की मेजबानी नहीं करता है, न ही डेस्कटॉप की अवधारणा को क्रियान्वित करता है जैसा कि कोई सामान्य प्रयोजन ऑपरेटिंग सिस्टम में मिलने की उम्मीद कर सकता है। टीपीएफ एप्लिकेशन स्रोत कोड सामान्यतः बाहरी सिस्टम में संग्रहीत किया जाता है, और इसी तरह ऑफ़लाइन भी बनाया जाता है। z/TPF 1.1 से प्रारंभ करके, [[Linux]] समर्थित बिल्ड प्लेटफ़ॉर्म है; z/TPF ऑपरेशन के लिए इच्छित निष्पादन योग्य प्रोग्रामों को s390x-ibm-linux के लिए [[निष्पादन योग्य और लिंक करने योग्य प्रारूप]] का पालन करना होगा। | एक विशेष प्रयोजन ऑपरेटिंग सिस्टम होने के नाते, टीपीएफ कंपाइलर/असेंबलर, टेक्स्ट एडिटर की मेजबानी नहीं करता है, न ही डेस्कटॉप की अवधारणा को क्रियान्वित करता है जैसा कि कोई सामान्य प्रयोजन ऑपरेटिंग सिस्टम में मिलने की उम्मीद कर सकता है। टीपीएफ एप्लिकेशन स्रोत कोड सामान्यतः बाहरी सिस्टम में संग्रहीत किया जाता है, और इसी तरह ऑफ़लाइन भी बनाया जाता है। z/TPF 1.1 से प्रारंभ करके, [[Linux]] समर्थित बिल्ड प्लेटफ़ॉर्म है; z/TPF ऑपरेशन के लिए इच्छित निष्पादन योग्य प्रोग्रामों को s390x-ibm-linux के लिए [[निष्पादन योग्य और लिंक करने योग्य प्रारूप]] का पालन करना होगा। | ||
टीपीएफ का उपयोग करने के लिए इसके <u>कमांड गाइड</u> का ज्ञान आवश्यक है<ref>{{Cite web|url=https://www.ibm.com/support/knowledgecenter/SSB23S_1.1.0.15/gtpo1/hfmsgs.html|title=z/TPF Operations Command Guide|last=IBM Corporation|website=[[IBM]] |date=29 January 2019 }}</ref> चूंकि ऑनलाइन कमांड डायरेक्टरी या मैन/हेल्प सुविधा के लिए कोई समर्थन नहीं है, जिसके उपयोगकर्ता आदी हो सकते हैं। टीपीएफ के सिस्टम प्रशासन के लिए आईबीएम द्वारा बनाए और भेजे गए कमांड को कार्यात्मक संदेश कहा जाता है - सामान्यतः इसे जेड-संदेश के रूप में जाना जाता है, क्योंकि वह सभी अक्षर | टीपीएफ का उपयोग करने के लिए इसके <u>कमांड गाइड</u> का ज्ञान आवश्यक है<ref>{{Cite web|url=https://www.ibm.com/support/knowledgecenter/SSB23S_1.1.0.15/gtpo1/hfmsgs.html|title=z/TPF Operations Command Guide|last=IBM Corporation|website=[[IBM]] |date=29 January 2019 }}</ref> चूंकि ऑनलाइन कमांड '''"डायरेक्टरी"''' या '''"मैन"'''/हेल्प सुविधा के लिए कोई समर्थन नहीं है, जिसके उपयोगकर्ता आदी हो सकते हैं। टीपीएफ के सिस्टम प्रशासन के लिए आईबीएम द्वारा बनाए और भेजे गए कमांड को '''"कार्यात्मक संदेश"''' कहा जाता है - सामान्यतः इसे '''"जेड-संदेश"''' के रूप में जाना जाता है, क्योंकि वह सभी अक्षर '''"जेड"''' के साथ उपसर्ग किए जाते हैं। अन्य पत्र आरक्षित हैं जिससे कि ग्राहक अपने स्वयं के आदेश लिख सकें। | ||
टीपीएफ वितरित क्लाइंट-सर्वर मोड में डिबगिंग क्रियान्वित करता है, जो सिस्टम की हेडलेस, मल्टी-प्रोसेसिंग प्रकृति के कारण आवश्यक है: किसी कार्य को फंसाने के लिए पूरे सिस्टम को रोकना अत्यधिक प्रतिकूल होगा। डिबगर पैकेज तीसरे पक्ष के विक्रेताओं द्वारा विकसित किए गए हैं, जिन्होंने टीपीएफ होस्ट पर आवश्यक ब्रेक/जारी संचालन के लिए बहुत भिन्न दृष्टिकोण अपनाए, डिबगर क्लाइंट चलाने वाले मानव डेवलपर और सर्वर-साइड डिबग नियंत्रक के मध्य यातायात में उपयोग किए जाने वाले अद्वितीय संचार प्रोटोकॉल को क्रियान्वित किया, साथ ही साथ क्लाइंट साइड पर डिबगर प्रोग्राम संचालन के रूप और कार्य भी किए। थर्ड पार्टी डिबगर पैकेज के दो उदाहरण बेडफोर्ड एसोसिएट्स के स्टेप बाय स्टेप ट्रेस हैं<ref>{{cite web|last=Bedford Associates|title=बेडफोर्ड एसोसिएट्स, इंक.|url=http://www.bedfordit.com/|access-date=October 17, 2012}}</ref> और सीएमएसटीपीएफ, टीपीएफ/जीआई, और जेडटीपीएफजीआई, सभी टीपीएफ सॉफ्टवेयर, इंक. से।<ref>{{cite web|last=TPF Software|title=टीपीएफ सॉफ्टवेयर, इंक.|url=http://www.tpfsoftware.com/|access-date=October 17, 2012}}</ref> कोई भी पैकेज न तब दूसरे के साथ और न ही आईबीएम की अपनी प्रस्तुति के साथ पूरी तरह अनुकूल है। आईबीएम की डिबगिंग क्लाइंट प्रस्तुति को आईबीएम टीपीएफ टूलकिट नामक | टीपीएफ वितरित क्लाइंट-सर्वर मोड में डिबगिंग क्रियान्वित करता है, जो सिस्टम की हेडलेस, मल्टी-प्रोसेसिंग प्रकृति के कारण आवश्यक है: किसी कार्य को फंसाने के लिए पूरे सिस्टम को रोकना अत्यधिक प्रतिकूल होगा। डिबगर पैकेज तीसरे पक्ष के विक्रेताओं द्वारा विकसित किए गए हैं, जिन्होंने टीपीएफ होस्ट पर आवश्यक ब्रेक/जारी संचालन के लिए बहुत भिन्न दृष्टिकोण अपनाए, डिबगर क्लाइंट चलाने वाले मानव डेवलपर और सर्वर-साइड डिबग नियंत्रक के मध्य यातायात में उपयोग किए जाने वाले अद्वितीय संचार प्रोटोकॉल को क्रियान्वित किया, साथ ही साथ क्लाइंट साइड पर डिबगर प्रोग्राम संचालन के रूप और कार्य भी किए। थर्ड पार्टी डिबगर पैकेज के दो उदाहरण बेडफोर्ड एसोसिएट्स के स्टेप बाय स्टेप ट्रेस हैं<ref>{{cite web|last=Bedford Associates|title=बेडफोर्ड एसोसिएट्स, इंक.|url=http://www.bedfordit.com/|access-date=October 17, 2012}}</ref> और सीएमएसटीपीएफ, टीपीएफ/जीआई, और जेडटीपीएफजीआई, सभी टीपीएफ सॉफ्टवेयर, इंक. से।<ref>{{cite web|last=TPF Software|title=टीपीएफ सॉफ्टवेयर, इंक.|url=http://www.tpfsoftware.com/|access-date=October 17, 2012}}</ref> कोई भी पैकेज न तब दूसरे के साथ और न ही आईबीएम की अपनी प्रस्तुति के साथ पूरी तरह अनुकूल है। आईबीएम की डिबगिंग क्लाइंट प्रस्तुति को आईबीएम टीपीएफ टूलकिट नामक आईडीई में पैक किया गया है।<ref>{{Cite web|url=https://www.ibm.com/us-en/marketplace/ibm-tpf-toolkit|title=आईबीएम टीपीएफ टूलकिट अवलोकन|last=IBM Corporation|website=[[IBM]] |date=Dec 2017|access-date=10 May 2018}}</ref> | ||
===टीपीएफ क्या है=== | ===टीपीएफ क्या है=== | ||
टीपीएफ को समर्थित नेटवर्क से संदेशों को किसी अन्य स्थान पर स्विच करने, किसी एप्लिकेशन (प्रोग्राम के विशिष्ट समूह) पर रूट करने या डेटाबेस रिकॉर्ड तक अत्यधिक कुशल पहुंच की अनुमति देने के लिए अत्यधिक अनुकूलित किया गया है। | टीपीएफ को समर्थित नेटवर्क से संदेशों को किसी अन्य स्थान पर स्विच करने, किसी एप्लिकेशन (प्रोग्राम के विशिष्ट समूह) पर रूट करने या डेटाबेस रिकॉर्ड तक अत्यधिक कुशल पहुंच की अनुमति देने के लिए अत्यधिक अनुकूलित किया गया है। | ||
====डेटा रिकॉर्ड==== | ====डेटा रिकॉर्ड==== | ||
ऐतिहासिक रूप से, टीपीएफ सिस्टम के सभी डेटा को 381, 1055 और 4K बाइट्स के निश्चित रिकॉर्ड (और मेमोरी ब्लॉक) आकार में फिट होना था। यह आंशिक रूप से DASD पर स्थित ब्लॉकों के भौतिक रिकॉर्ड आकार के कारण था। ऑपरेटिंग सिस्टम के किसी भी हिस्से को फ़ाइल संचालन के समय बड़े डेटा इकाइयों को छोटे में तोड़ने और पढ़ने के संचालन के समय उन्हें पुन: संयोजन करने से बहुत अधिक ओवरहेड बचाया गया था। चूँकि IBM हार्डवेयर चैनलों और चैनल प्रोग्रामों के उपयोग के माध्यम से I/O करता है, TPF अपने I/O को करने के लिए बहुत छोटे और कुशल चैनल प्रोग्राम तैयार करेगा - यह सब गति के नाम पर। चूंकि प्रारंभिक दिनों में स्टोरेज मीडिया के आकार को भी महत्व दिया जाता था - चाहे वह मेमोरी हो या डिस्क, टीपीएफ एप्लिकेशन बहुत कम संसाधन का उपयोग करते हुए बहुत शक्तिशाली काम करने में विकसित हुए। | ऐतिहासिक रूप से, टीपीएफ सिस्टम के सभी डेटा को 381, 1055 और 4K बाइट्स के निश्चित रिकॉर्ड (और मेमोरी ब्लॉक) आकार में फिट होना था। यह आंशिक रूप से DASD पर स्थित ब्लॉकों के भौतिक रिकॉर्ड आकार के कारण था। ऑपरेटिंग सिस्टम के किसी भी हिस्से को फ़ाइल संचालन के समय बड़े डेटा इकाइयों को छोटे में तोड़ने और पढ़ने के संचालन के समय उन्हें पुन: संयोजन करने से बहुत अधिक ओवरहेड बचाया गया था। चूँकि IBM हार्डवेयर '''चैनलों''' और '''चैनल प्रोग्रामों''' के उपयोग के माध्यम से I/O करता है, TPF अपने I/O को करने के लिए बहुत छोटे और कुशल चैनल प्रोग्राम तैयार करेगा - यह सब गति के नाम पर। चूंकि प्रारंभिक दिनों में स्टोरेज मीडिया के आकार को भी महत्व दिया जाता था - चाहे वह मेमोरी हो या डिस्क, टीपीएफ एप्लिकेशन बहुत कम संसाधन का उपयोग करते हुए बहुत शक्तिशाली काम करने में विकसित हुए। | ||
आज, इनमें से अधिकांश सीमाएँ हटा दी गई हैं। वास्तव में, केवल विरासत समर्थन के कारण ही 4K से छोटे DASD रिकॉर्ड अभी भी उपयोग किए जाते हैं। DASD विधि में हुई प्रगति के साथ, 4K रिकॉर्ड को पढ़ना/लिखना 1055 बाइट रिकॉर्ड जितना ही कुशल है। समान प्रगति ने प्रत्येक डिवाइस की क्षमता में वृद्धि की है जिससे कि डेटा को यथासंभव सबसे छोटे मॉडल में पैक करने की क्षमता पर कोई प्रीमियम न रखा जाए। | आज, इनमें से अधिकांश सीमाएँ हटा दी गई हैं। वास्तव में, केवल विरासत समर्थन के कारण ही 4K से छोटे DASD रिकॉर्ड अभी भी उपयोग किए जाते हैं। DASD विधि में हुई प्रगति के साथ, 4K रिकॉर्ड को पढ़ना/लिखना 1055 बाइट रिकॉर्ड जितना ही कुशल है। समान प्रगति ने प्रत्येक डिवाइस की क्षमता में वृद्धि की है जिससे कि डेटा को यथासंभव सबसे छोटे मॉडल में पैक करने की क्षमता पर कोई प्रीमियम न रखा जाए। | ||
====कार्यक्रम और निवास==== | ====कार्यक्रम और निवास==== | ||
टीपीएफ ने अपने इतिहास में विभिन्न बिंदुओं पर अपने कार्यक्रम खंडों को 381, 1055 और 4K बाइट-आकार के रिकॉर्ड के रूप में आवंटित किया था। प्रत्येक | टीपीएफ ने अपने इतिहास में विभिन्न बिंदुओं पर अपने कार्यक्रम '''खंडों''' को 381, 1055 और 4K बाइट-आकार के '''रिकॉर्ड''' के रूप में आवंटित किया था। प्रत्येक लोडर में ही रिकॉर्ड सम्मिलित था; सामान्यतः व्यापक अनुप्रयोग के लिए संभवतः दसियों या यहां तक कि सैकड़ों खंडों की आवश्यकता होती है। टीपीएफ के इतिहास के पहले चालीस वर्षों में, यह लोडर कभी भी [[लिंकर (कंप्यूटिंग)]]|लिंक-संपादित नहीं थे। इसके अतिरिक्त, रिलोकेटेबल ऑब्जेक्ट कोड (एसेम्बलर से सीधा आउटपुट) को मेमोरी में रखा गया था, इसके ''आंतरिक'' (सेल्फ-रेफरेंशियल) रिलोकेटेबल प्रतीकों को हल किया गया था, फिर पूरी छवि को पश्चात् में सिस्टम में लोड करने के लिए फाइल में लिखा गया था। इसने चुनौतीपूर्ण प्रोग्रामिंग वातावरण तैयार किया जिसमें ''एक-दूसरे से संबंधित लोडर एक-दूसरे को सीधे संबोधित नहीं कर सकते थे'', उनके मध्य नियंत्रण हस्तांतरण को '''ENTER/BACK''' ''सिस्टम सेवा'' के रूप में क्रियान्वित किया गया। | ||
एसीपी/टीपीएफ के प्रारंभिक दिनों (लगभग 1965) में, मेमोरी स्पेस गंभीर रूप से सीमित था, जिसने फ़ाइल-रेजिडेंट और कोर-रेजिडेंट प्रोग्राम के मध्य अंतर को जन्म दिया - केवल सबसे अधिक उपयोग किए जाने वाले एप्लिकेशन प्रोग्राम को मेमोरी में लिखा गया था और कभी भी हटाया नहीं गया था (कोर-रेजिडेंसी); बाकी को फ़ाइल में संग्रहीत किया गया और मांग पर पढ़ा गया, उनके बैकिंग मेमोरी बफ़र्स को निष्पादन के पश्चात् जारी किया गया। | एसीपी/टीपीएफ के प्रारंभिक दिनों (लगभग 1965) में, मेमोरी स्पेस गंभीर रूप से सीमित था, जिसने '''फ़ाइल-रेजिडेंट''' और '''कोर-रेजिडेंट''' प्रोग्राम के मध्य अंतर को जन्म दिया - केवल सबसे अधिक उपयोग किए जाने वाले एप्लिकेशन प्रोग्राम को मेमोरी में लिखा गया था और कभी भी हटाया नहीं गया था '''(कोर-रेजिडेंसी)'''; बाकी को फ़ाइल में संग्रहीत किया गया और मांग पर पढ़ा गया, उनके बैकिंग मेमोरी बफ़र्स को निष्पादन के पश्चात् जारी किया गया। | ||
संस्करण 3.0 में टीपीएफ में सी (प्रोग्रामिंग भाषा) का परिचय पहली बार | संस्करण 3.0 में टीपीएफ में सी (प्रोग्रामिंग भाषा) का परिचय पहली बार लोडर सम्मेलनों के अनुरूप क्रियान्वित किया गया था, जिसमें लिंकेज संपादन की अनुपस्थिति भी सम्मिलित थी। इस योजना ने शीघ्र ही स्वयं को सबसे सरल सी प्रोग्राम के अतिरिक्त किसी अन्य चीज़ के लिए अव्यावहारिक सिद्ध करना कर दिया। टीपीएफ 4.1 में, सही मायने में और पूरी तरह से लिंक किए गए '''लोड मॉड्यूल''' को टीपीएफ से प्रस्तुतकिया गया था। इन्हें TPF-विशिष्ट [[हेडर फ़ाइलें]] का उपयोग करके z/OS C/C++ कंपाइलर के साथ संकलित किया गया और '''IEWL''' के साथ जोड़ा गया, जिसके परिणामस्वरूप z/OS-अनुरूप लोड मॉड्यूल प्राप्त हुआ, जिसे किसी भी तरह से पारंपरिक '''TPF''' लोडर नहीं माना जा सकता है। टीपीएफ लोडर को z/OS-अद्वितीय ''लोड मॉड्यूल'' फ़ाइल प्रारूप को पढ़ने के लिए बढ़ाया गया था, फिर फ़ाइल-निवासी लोड मॉड्यूल के अनुभागों को मेमोरी में ले जाया गया; इस मध्य, असेंबली भाषा कार्यक्रम टीपीएफ के ''सेगमेंट'' मॉडल तक ही सीमित रहे, जिससे असेंबलर में लिखे गए अनुप्रयोगों और उच्च स्तरीय भाषाओं (एचएलएल) में लिखे गए अनुप्रयोगों के मध्य स्पष्ट असमानता उत्पन्न हुई। | ||
z/TPF 1.1 पर, सभी स्रोत भाषा प्रकार वैचारिक रूप से एकीकृत थे और [[निष्पादन योग्य और लिंकिंग प्रारूप]] विनिर्देश के अनुरूप पूरी तरह से लिंक-संपादित थे। ''सेगमेंट'' अवधारणा अप्रचलित हो गई, जिसका अर्थ है कि ''किसी भी'' स्रोत भाषा में लिखा गया ''कोई भी'' प्रोग्राम - जिसमें असेंबलर भी सम्मिलित है - वर्तमान किसी भी आकार का हो सकता है। इसके अतिरिक्त, बाहरी संदर्भ संभव हो गए, और भिन्न-भिन्न स्रोत कोड प्रोग्राम जो कभी ''सेगमेंट'' थे, वर्तमान सीधे साझा ऑब्जेक्ट में साथ जोड़े जा सकते हैं। मूल्य बिंदु यह है कि महत्वपूर्ण विरासत अनुप्रयोग सरल ''रीपैकेजिंग'' के माध्यम से उत्तम दक्षता से लाभ उठा सकते हैं - एकल साझा ऑब्जेक्ट मॉड्यूल के सदस्यों के मध्य किए गए कॉल में वर्तमान सिस्टम की ''ENTER/BACK'' सेवा को कॉल करने की तुलना में रन टाइम पर बहुत कम पथलंबाई होती है। समान साझा ऑब्जेक्ट के सदस्य वर्तमान लिखने योग्य डेटा क्षेत्रों को सीधे z/TPF 1.1 पर प्रारंभ की गई [[लिखने पर नकल]] कार्यक्षमता के कारण साझा कर सकते हैं; जो संयोगवश टीपीएफ की [[पुनर्प्रवेश (कंप्यूटिंग)]] आवश्यकताओं को पुष्ट करता है। | z/TPF 1.1 पर, सभी स्रोत भाषा प्रकार वैचारिक रूप से एकीकृत थे '''और''' [[निष्पादन योग्य और लिंकिंग प्रारूप]] विनिर्देश के अनुरूप पूरी तरह से लिंक-संपादित थे। ''सेगमेंट'' अवधारणा अप्रचलित हो गई, जिसका अर्थ है कि ''किसी भी'' स्रोत भाषा में लिखा गया ''कोई भी'' प्रोग्राम - जिसमें असेंबलर भी सम्मिलित है - वर्तमान किसी भी आकार का हो सकता है। इसके अतिरिक्त, बाहरी संदर्भ संभव हो गए, और भिन्न-भिन्न स्रोत कोड प्रोग्राम जो कभी ''सेगमेंट'' थे, वर्तमान सीधे साझा ऑब्जेक्ट में साथ जोड़े जा सकते हैं। मूल्य बिंदु यह है कि महत्वपूर्ण विरासत अनुप्रयोग सरल ''रीपैकेजिंग'' के माध्यम से उत्तम दक्षता से लाभ उठा सकते हैं - एकल साझा ऑब्जेक्ट मॉड्यूल के सदस्यों के मध्य किए गए कॉल में वर्तमान सिस्टम की ''ENTER/BACK'' सेवा को कॉल करने की तुलना में रन टाइम पर बहुत कम पथलंबाई होती है। समान साझा ऑब्जेक्ट के सदस्य वर्तमान लिखने योग्य डेटा क्षेत्रों को सीधे z/TPF 1.1 पर प्रारंभ की गई [[लिखने पर नकल]] कार्यक्षमता के कारण साझा कर सकते हैं; जो संयोगवश टीपीएफ की [[पुनर्प्रवेश (कंप्यूटिंग)]] आवश्यकताओं को पुष्ट करता है। | ||
फ़ाइल- और मेमोरी-रेजीडेंसी की अवधारणाओं को भी z/TPF डिज़ाइन बिंदु के कारण अप्रचलित बना दिया गया था, जिसमें सभी प्रोग्रामों को हर समय मेमोरी में रेजिडेंट रखने की मांग की गई थी। | फ़ाइल- और मेमोरी-रेजीडेंसी की अवधारणाओं को भी z/TPF डिज़ाइन बिंदु के कारण अप्रचलित बना दिया गया था, जिसमें सभी प्रोग्रामों को हर समय मेमोरी में रेजिडेंट रखने की मांग की गई थी। | ||
Revision as of 10:35, 9 August 2023
| File:आईबीएम लोगो.svg | |
| डेवलपर | आईबीएम |
|---|---|
| लिखा हुआ | z/आर्किटेक्चर असेंबली भाषा, सी, सी++ |
| ओएस परिवार | z/आर्किटेक्चर असेंबली लैंग्वेज (z/TPF), ESA/390 असेंबली लैंग्वेज (TPF4) |
| काम करने की अवस्था | मौजूदा |
| स्रोत मॉडल | बंद स्रोत (स्रोत कोड प्रतिबंधों के साथ लाइसेंस प्राप्त उपयोगकर्ताओं के लिए उपलब्ध है) |
| Latest release | 1.1.0.2020[1] |
| प्लेटफार्मों | आईबीएम सिस्टम जेड (जेड/टीपीएफ), ईएसए/390 (टीपीएफ4) |
| कर्नेल प्रकार | वास्तविक समय |
| डिफ़ॉल्ट उपयोगकर्ता इंटरफ़ेस | 3215 3270 |
| लाइसेंस | मालिकाना मासिक लाइसेंस शुल्क (एमएलसी) |
| आधिकारिक वेबसाइट | z/TPF उत्पाद पृष्ठ |
| History of IBM mainframe operating systems |
|---|
लेनदेन प्रसंस्करण सुविधा (टीपीएफ)[2] आईबीएम मेनफ्रेम कंप्यूटरों के लिए आईबीएम वास्तविक समय ऑपरेटिंग सिस्टम है जो आईबीएम सिस्टम/360 परिवार से आया है, जिसमें आईबीएम सिस्टम z और आईबीएम सिस्टम जेड सम्मिलित हैं।
टीपीएफ तेज, उच्च-मात्रा, उच्च-थ्रूपुट लेनदेन प्रसंस्करण प्रदान करता है, बड़े, भौगोलिक रूप से फैले हुए नेटवर्क में अनिवार्य रूप से सरल लेनदेन के बड़े, निरंतर भार को संभालता है।
जबकि अन्य औद्योगिक-शक्ति लेनदेन प्रसंस्करण प्रणालियाँ हैं, विशेष रूप से आईबीएम की अपनी सीआईसीएस और आईबीएम सूचना प्रबंधन प्रणाली, टीपीएफ की विशेषता अत्यधिक मात्रा, बड़ी संख्या में समवर्ती उपयोगकर्ता और बहुत तेज़ प्रतिक्रिया समय है। उदाहरण के लिए, यह चरम छुट्टियों की खरीदारी के मौसम के समय वीज़ा इंक लेनदेन प्रसंस्करण को संभालता है।[3][2]
टीपीएफ यात्री आरक्षण एप्लिकेशन क्रमादेशित एयरलाइन आरक्षण प्रणाली, या इसका अंतर्राष्ट्रीय संस्करण आईपीएआरएस, अनेक एयरलाइनों द्वारा उपयोग किया जाता है। PARS एप्लिकेशन प्रोग्राम है; टीपीएफ ऑपरेटिंग सिस्टम है.
टीपीएफ के प्रमुख वैकल्पिक घटकों में से उच्च प्रदर्शन, विशेष डेटाबेस सुविधा है जिसे टीपीएफ डेटाबेस सुविधा (टीपीएफडीएफ) कहा जाता है।[4] टीपीएफ का करीबी रिश्तेदार, लेनदेन मॉनिटर एएलसीएस लेनदेन मॉनिटर, आईबीएम द्वारा टीपीएफ सेवाओं को अधिक सामान्य मेनफ्रेम ऑपरेटिंग सिस्टम एमवीएस, वर्तमान जेड/ओएस में एकीकृत करने के लिए विकसित किया गया था।
इतिहास
टीपीएफ एयरलाइंस नियंत्रण कार्यक्रम (एसीपी) से विकसित हुआ, जो 1960 के दशक के मध्य में प्रमुख उत्तरी अमेरिकी और यूरोपीय एयरलाइंस के सहयोग से आईबीएम द्वारा विकसित मुफ्त पैकेज था। 1979 में, IBM ने ACP के प्रतिस्थापन के रूप में और मूल्य वाले सॉफ़्टवेयर उत्पाद के रूप में TPF को प्रस्तुतकिया। नया नाम गैर-एयरलाइन संबंधित संस्थाओं में इसके व्यापक सीमा और विकास का सुझाव देता है।
प्रदर्शन कारणों से टीपीएफ पारंपरिक रूप से आईबीएम सिस्टम/370 असेंबली भाषा वातावरण था, और अनेक टीपीएफ असेंबलर अनुप्रयोग कायम हैं। चूँकि, टीपीएफ के नवीनतम संस्करण [[सी (प्रोग्रामिंग भाषा)]] के उपयोग को प्रोत्साहित करते हैं। सब्रेटॉक नामक अन्य प्रोग्रामिंग भाषा का जन्म और मृत्यु टीपीएफ पर हुई।
आईबीएम ने सितंबर 2005 में टीपीएफ की वर्तमान रिलीज, जिसे जेड/टीपीएफ वी1.1 कहा जाता है, की डिलीवरी की घोषणा की। सबसे महत्वपूर्ण बात यह है कि, जेड/टीपीएफ 64-बिट एड्रेसिंग जोड़ता है और 64-बिट जीएनयू डेवलपमेंट टूल्स के उपयोग को अनिवार्य बनाता है।[5][6] जीएनयू कंपाइलर संग्रह और DIGNUS सिस्टम्स/C++ और सिस्टम्स/C z/TPF के लिए एकमात्र समर्थित कंपाइलर हैं। टीपीएफ 4.1 से जेड/टीपीएफ पर जाने पर डिग्नस कंपाइलर कम स्रोत कोड परिवर्तन की प्रस्तुति करते हैं।
उपयोगकर्ता
वर्तमान उपयोगकर्ताओं में सेबर (कंप्यूटर सिस्टम) (आरक्षण), वीज़ा इंक.|वीज़ा इंक. (प्राधिकरण), अमेरिकन एयरलाइंस, सम्मिलित हैं।[7] अमेरिकन एक्सप्रेस (प्राधिकरण), डीएक्ससी टेक्नोलॉजी शेयर्स (आरक्षण), एमट्रैक, मैरियट इंटरनेशनल, ट्रैवलपोर्ट (गैलीलियो, अपोलो, वर्ल्डस्पैन), सिटी बैंक , ट्रेनीतालिया (आरक्षण), डेल्टा एयरलाइंस (आरक्षण और संचालन) और जापान एयरलाइंस।[8]
परिचालन वातावरण
मजबूती के साथ जोड़ना
चूँकि आईबीएम के IBM 3083 का लक्ष्य टीपीएफ को "तेज़... यूनिप्रोसेसर" पर चलाना था,[9] टीपीएफ मल्टीप्रोसेसर पर चलने में सक्षम है, अर्थात उन सिस्टमों पर जिनमें से अधिक सीपीयू हैं। एलपीएआर के अंदर, सीपीयू को निर्देश स्ट्रीम या बस 'आई-स्ट्रीम' के रूप में जाना जाता है। एक से अधिक आई-स्ट्रीम के साथ एलपीएआर पर चलने पर, टीपीएफ को 'कसकर युग्मित' चलने वाला कहा जाता है। टीपीएफ एसएमपी अवधारणाओं का पालन करता है; मेमोरी पतों के मध्य गैर-समान मेमोरी एक्सेस-आधारित भेद की कोई अवधारणा उपस्तिथ नहीं है।
सीपीयू तैयार सूची की गहराई को किसी भी आने वाले लेनदेन के प्राप्त होने पर मापा जाता है, और सबसे कम मांग के साथ आई-स्ट्रीम के लिए कतारबद्ध किया जाता है, इस प्रकार उपलब्ध प्रोसेसर के मध्य निरंतर लोड संतुलन बनाए रखा जाता है। ऐसे स्थितियों में जहां 'लूज़ली कपल' कॉन्फ़िगरेशन मल्टीप्रोसेसर 'सीपीसी (सेंट्रल प्रोसेसिंग कॉम्प्लेक्स, अर्थात सिस्टम कैबिनेट में पैक की गई भौतिक मशीन) द्वारा पॉप्युलेट किया जाता है, सममित मल्टीप्रोसेसिंग सीपीसी के अंदर होती है जैसा कि यहां वर्णित है, जबकि अंतर-सीपीसी संसाधनों का साझाकरण नीचे 'लूज़ली कपल' के अनुसार वर्णित के अनुसार होता है।
टीपीएफ आर्किटेक्चर में, सभी मेमोरी (4KB आकार के उपसर्ग क्षेत्र को छोड़कर) सभी आई-स्ट्रीम के मध्य साझा की जाती है। ऐसे उदाहरणों में जहां मेमोरी-रेजिडेंट डेटा को आई-स्ट्रीम द्वारा भिन्न रखा जाना चाहिए या होना चाहिए, प्रोग्रामर सामान्यतः आई-स्ट्रीम की संख्या के सामान्तर अनेक उपखंडों में भंडारण क्षेत्र आवंटित करता है, फिर आवंटित क्षेत्र का आधार पता लेकर वांछित आई-स्ट्रीम संबंधित क्षेत्र तक पहुंचता है, और इसमें आई-स्ट्रीम सापेक्ष संख्या के उत्पाद को प्रत्येक उपधारा के आकार से गुणा करता है।
शिथिल युग्मित
टीपीएफ सामान्य डेटाबेस से जुड़ने और संचालन करने में अनेक मेनफ्रेम (किसी भी आकार के - चाहे वह एकल आई-स्ट्रीम से एकाधिक आई-स्ट्रीम हो) का समर्थन करने में सक्षम है। वर्तमान में, 32 आईबीएम मेनफ्रेम टीपीएफ डेटाबेस साझा कर सकते हैं; यदि ऐसी कोई प्रणाली प्रचालन में होती, तब इसे 32-वे शिथिल युग्मित कहा जाता। सबसे सरल ढीली युग्मन प्रणाली दो आईबीएम मेनफ्रेम होगी जो डीएएसडी (डायरेक्ट एक्सेस स्टोरेज डिवाइस) साझा करेगी। इस स्थितियोंमें, नियंत्रण प्रोग्राम समान रूप से मेमोरी में लोड किया जाएगा और DASD पर प्रत्येक प्रोग्राम या रिकॉर्ड को संभावित रूप से मेनफ्रेम द्वारा एक्सेस किया जा सकता है।
शिथिल युग्मित प्रणाली पर डेटा रिकॉर्ड के मध्य पहुंच को क्रमबद्ध करने के लिए, रिकॉर्ड लॉकिंग के रूप में ज्ञात अभ्यास का उपयोग किया जाना चाहिए। इसका कारण यह है कि जब मेनफ्रेम प्रोसेसर रिकॉर्ड पर होल्ड प्राप्त करता है, तब तंत्र को अन्य सभी प्रोसेसर को समान होल्ड प्राप्त करने से रोकना चाहिए और अनुरोध करने वाले प्रोसेसर को सूचित करना चाहिए कि वह प्रतीक्षा कर रहे हैं। किसी भी कसकर युग्मित प्रणाली के अंदर, रिकॉर्ड होल्ड टेबल के उपयोग के माध्यम से आई-स्ट्रीम के मध्य इसे प्रबंधित करना आसान है। चूँकि, जब DASD नियंत्रण इकाई में TPF प्रोसेसर से लॉक प्राप्त होता है, तब बाहरी प्रक्रिया का उपयोग किया जाना चाहिए। ऐतिहासिक रूप से, रिकॉर्ड लॉकिंग डीएएसडी नियंत्रण इकाई में एलएलएफ (सीमित लॉकिंग सुविधा) और पश्चात् में ईएलएलएफ (विस्तारित) नामक आरपीवाईए के माध्यम से पूरा किया गया था। एलएलएफ और ईएलएलएफ दोनों को मल्टीपाथिंग लॉक फैसिलिटी (एमपीएलएफ) द्वारा प्रतिस्थापित किया गया था। क्लस्टर्ड (शिथिल रूप से युग्मित) z/TPF को चलाने के लिए सभी डिस्क नियंत्रण इकाइयों में या तब MPLF या वैकल्पिक लॉकिंग डिवाइस की आवश्यकता होती है लूस कपलिंग सुविधा कहा जाता है।[10][11]
प्रोसेसर साझा रिकॉर्ड
जिन रिकॉर्ड्स को निश्चित रूप से रिकॉर्ड लॉकिंग प्रक्रिया द्वारा प्रबंधित किया जाना चाहिए, वह हैं जो प्रोसेसर साझा किए गए हैं। टीपीएफ में, अधिकांश रिकॉर्ड एक्सेस रिकॉर्ड प्रकार और ऑर्डिनल का उपयोग करके किया जाता है। 100 रिकॉर्ड या ऑर्डिनल्स के साथ 'एफआरईडी' के टीपीएफ सिस्टम में रिकॉर्ड प्रकार को देखते हुए, प्रोसेसर साझा योजना में, रिकॉर्ड प्रकार 'एफआरईडी' ऑर्डिनल '5' डीएएसडी पर बिल्कुल उसी फ़ाइल पते को हल करेगा - जिसके लिए रिकॉर्ड लॉकिंग तंत्र के उपयोग की आवश्यकता होगी।
टीपीएफ सिस्टम पर सभी प्रोसेसर द्वारा साझा किए गए रिकॉर्ड को ही फ़ाइल पते के माध्यम से एक्सेस किया जाएगा जो ही स्थान पर हल होगा।
प्रोसेसर अद्वितीय रिकॉर्ड
एक प्रोसेसर अद्वितीय रिकॉर्ड वह होता है जिसे इस तरह परिभाषित किया जाता है कि शिथिल युग्मित कॉम्प्लेक्स में होने वाले प्रत्येक प्रोसेसर में 'FRED' का रिकॉर्ड प्रकार और संभवतः 100 ऑर्डिनल्स होते हैं। चूँकि, यदि किसी भी 2 या अधिक प्रोसेसर पर कोई उपयोगकर्ता उस फ़ाइल पते की जांच करता है जो रिकॉर्ड प्रकार 'FRED', क्रमिक '5' को हल करता है, तब वह देखेंगे कि भिन्न भौतिक पते का उपयोग किया गया है।
टीपीएफ विशेषताएँ
टीपीएफ क्या नहीं है
टीपीएफ सामान्य प्रयोजन वाला ऑपरेटिंग सिस्टम नहीं है। टीपीएफ की विशेष भूमिका लेनदेन इनपुट संदेशों को संसाधित करना है, फिर आउटपुट संदेशों को 1:1 के आधार पर अत्यधिक उच्च मात्रा में कम अधिकतम व्यतीत समय सीमा के साथ लौटाना है।
टीपीएफ में कोई अंतर्निहित ग्राफिकल यूजर इंटरफेस कार्यक्षमता नहीं है, और टीपीएफ ने कभी भी प्रत्यक्ष ग्राफिकल डिस्प्ले सुविधाओं की प्रस्तुति नहीं की है: इसे होस्ट पर क्रियान्वित करना वास्तविक समय सिस्टम संसाधनों का अनावश्यक और संभावित रूप से हानिकारक मोड़ माना जाएगा। टीपीएफ का उपयोगकर्ता इंटरफ़ेस सरल टेक्स्ट डिस्प्ले टर्मिनलों के साथ कमांड-लाइन संचालित है जो ऊपर की ओर स्क्रॉल करता है, और टीपीएफ प्राइम सीआरएएस पर कोई माउस-संचालित कर्सर, विंडो या आइकन नहीं हैं[12] (कंप्यूटर रूम एजेंट समूह - जिसे "ऑपरेटर का कंसोल" के रूप में सबसे अच्छा माना जाता है)। चरित्र संदेशों का उद्देश्य मानव उपयोगकर्ताओं के साथ संचार का माध्यम होना है। एक्स विंडो सिस्टम के बिना यूनिक्स के समान, सभी कार्य कमांड लाइन के उपयोग के माध्यम से पूरा किया जाता है। ऐसे अनेक उत्पाद उपलब्ध हैं जो प्राइम सीआरएएस से जुड़ते हैं और टीपीएफ ऑपरेटर को ग्राफिकल इंटरफ़ेस वेरिएबल प्रदान करते हैं, जैसे टीपीएफ ऑपरेशंस सर्वर।[13] अंतिम उपयोगकर्ताओं के लिए ग्राफ़िकल इंटरफ़ेस, यदि वांछित हो, बाहरी सिस्टम द्वारा प्रदान किया जाना चाहिए। ऐसे सिस्टम चरित्र सामग्री पर विश्लेषण करते हैं (स्क्रीन स्क्रैप देखें) और संदेश को उसके संदर्भ के आधार पर वांछित ग्राफिकल रूप में परिवर्तित करते हैं।
एक विशेष प्रयोजन ऑपरेटिंग सिस्टम होने के नाते, टीपीएफ कंपाइलर/असेंबलर, टेक्स्ट एडिटर की मेजबानी नहीं करता है, न ही डेस्कटॉप की अवधारणा को क्रियान्वित करता है जैसा कि कोई सामान्य प्रयोजन ऑपरेटिंग सिस्टम में मिलने की उम्मीद कर सकता है। टीपीएफ एप्लिकेशन स्रोत कोड सामान्यतः बाहरी सिस्टम में संग्रहीत किया जाता है, और इसी तरह ऑफ़लाइन भी बनाया जाता है। z/TPF 1.1 से प्रारंभ करके, Linux समर्थित बिल्ड प्लेटफ़ॉर्म है; z/TPF ऑपरेशन के लिए इच्छित निष्पादन योग्य प्रोग्रामों को s390x-ibm-linux के लिए निष्पादन योग्य और लिंक करने योग्य प्रारूप का पालन करना होगा।
टीपीएफ का उपयोग करने के लिए इसके कमांड गाइड का ज्ञान आवश्यक है[14] चूंकि ऑनलाइन कमांड "डायरेक्टरी" या "मैन"/हेल्प सुविधा के लिए कोई समर्थन नहीं है, जिसके उपयोगकर्ता आदी हो सकते हैं। टीपीएफ के सिस्टम प्रशासन के लिए आईबीएम द्वारा बनाए और भेजे गए कमांड को "कार्यात्मक संदेश" कहा जाता है - सामान्यतः इसे "जेड-संदेश" के रूप में जाना जाता है, क्योंकि वह सभी अक्षर "जेड" के साथ उपसर्ग किए जाते हैं। अन्य पत्र आरक्षित हैं जिससे कि ग्राहक अपने स्वयं के आदेश लिख सकें।
टीपीएफ वितरित क्लाइंट-सर्वर मोड में डिबगिंग क्रियान्वित करता है, जो सिस्टम की हेडलेस, मल्टी-प्रोसेसिंग प्रकृति के कारण आवश्यक है: किसी कार्य को फंसाने के लिए पूरे सिस्टम को रोकना अत्यधिक प्रतिकूल होगा। डिबगर पैकेज तीसरे पक्ष के विक्रेताओं द्वारा विकसित किए गए हैं, जिन्होंने टीपीएफ होस्ट पर आवश्यक ब्रेक/जारी संचालन के लिए बहुत भिन्न दृष्टिकोण अपनाए, डिबगर क्लाइंट चलाने वाले मानव डेवलपर और सर्वर-साइड डिबग नियंत्रक के मध्य यातायात में उपयोग किए जाने वाले अद्वितीय संचार प्रोटोकॉल को क्रियान्वित किया, साथ ही साथ क्लाइंट साइड पर डिबगर प्रोग्राम संचालन के रूप और कार्य भी किए। थर्ड पार्टी डिबगर पैकेज के दो उदाहरण बेडफोर्ड एसोसिएट्स के स्टेप बाय स्टेप ट्रेस हैं[15] और सीएमएसटीपीएफ, टीपीएफ/जीआई, और जेडटीपीएफजीआई, सभी टीपीएफ सॉफ्टवेयर, इंक. से।[16] कोई भी पैकेज न तब दूसरे के साथ और न ही आईबीएम की अपनी प्रस्तुति के साथ पूरी तरह अनुकूल है। आईबीएम की डिबगिंग क्लाइंट प्रस्तुति को आईबीएम टीपीएफ टूलकिट नामक आईडीई में पैक किया गया है।[17]
टीपीएफ क्या है
टीपीएफ को समर्थित नेटवर्क से संदेशों को किसी अन्य स्थान पर स्विच करने, किसी एप्लिकेशन (प्रोग्राम के विशिष्ट समूह) पर रूट करने या डेटाबेस रिकॉर्ड तक अत्यधिक कुशल पहुंच की अनुमति देने के लिए अत्यधिक अनुकूलित किया गया है।
डेटा रिकॉर्ड
ऐतिहासिक रूप से, टीपीएफ सिस्टम के सभी डेटा को 381, 1055 और 4K बाइट्स के निश्चित रिकॉर्ड (और मेमोरी ब्लॉक) आकार में फिट होना था। यह आंशिक रूप से DASD पर स्थित ब्लॉकों के भौतिक रिकॉर्ड आकार के कारण था। ऑपरेटिंग सिस्टम के किसी भी हिस्से को फ़ाइल संचालन के समय बड़े डेटा इकाइयों को छोटे में तोड़ने और पढ़ने के संचालन के समय उन्हें पुन: संयोजन करने से बहुत अधिक ओवरहेड बचाया गया था। चूँकि IBM हार्डवेयर चैनलों और चैनल प्रोग्रामों के उपयोग के माध्यम से I/O करता है, TPF अपने I/O को करने के लिए बहुत छोटे और कुशल चैनल प्रोग्राम तैयार करेगा - यह सब गति के नाम पर। चूंकि प्रारंभिक दिनों में स्टोरेज मीडिया के आकार को भी महत्व दिया जाता था - चाहे वह मेमोरी हो या डिस्क, टीपीएफ एप्लिकेशन बहुत कम संसाधन का उपयोग करते हुए बहुत शक्तिशाली काम करने में विकसित हुए।
आज, इनमें से अधिकांश सीमाएँ हटा दी गई हैं। वास्तव में, केवल विरासत समर्थन के कारण ही 4K से छोटे DASD रिकॉर्ड अभी भी उपयोग किए जाते हैं। DASD विधि में हुई प्रगति के साथ, 4K रिकॉर्ड को पढ़ना/लिखना 1055 बाइट रिकॉर्ड जितना ही कुशल है। समान प्रगति ने प्रत्येक डिवाइस की क्षमता में वृद्धि की है जिससे कि डेटा को यथासंभव सबसे छोटे मॉडल में पैक करने की क्षमता पर कोई प्रीमियम न रखा जाए।
कार्यक्रम और निवास
टीपीएफ ने अपने इतिहास में विभिन्न बिंदुओं पर अपने कार्यक्रम खंडों को 381, 1055 और 4K बाइट-आकार के रिकॉर्ड के रूप में आवंटित किया था। प्रत्येक लोडर में ही रिकॉर्ड सम्मिलित था; सामान्यतः व्यापक अनुप्रयोग के लिए संभवतः दसियों या यहां तक कि सैकड़ों खंडों की आवश्यकता होती है। टीपीएफ के इतिहास के पहले चालीस वर्षों में, यह लोडर कभी भी लिंकर (कंप्यूटिंग)|लिंक-संपादित नहीं थे। इसके अतिरिक्त, रिलोकेटेबल ऑब्जेक्ट कोड (एसेम्बलर से सीधा आउटपुट) को मेमोरी में रखा गया था, इसके आंतरिक (सेल्फ-रेफरेंशियल) रिलोकेटेबल प्रतीकों को हल किया गया था, फिर पूरी छवि को पश्चात् में सिस्टम में लोड करने के लिए फाइल में लिखा गया था। इसने चुनौतीपूर्ण प्रोग्रामिंग वातावरण तैयार किया जिसमें एक-दूसरे से संबंधित लोडर एक-दूसरे को सीधे संबोधित नहीं कर सकते थे, उनके मध्य नियंत्रण हस्तांतरण को ENTER/BACK सिस्टम सेवा के रूप में क्रियान्वित किया गया।
एसीपी/टीपीएफ के प्रारंभिक दिनों (लगभग 1965) में, मेमोरी स्पेस गंभीर रूप से सीमित था, जिसने फ़ाइल-रेजिडेंट और कोर-रेजिडेंट प्रोग्राम के मध्य अंतर को जन्म दिया - केवल सबसे अधिक उपयोग किए जाने वाले एप्लिकेशन प्रोग्राम को मेमोरी में लिखा गया था और कभी भी हटाया नहीं गया था (कोर-रेजिडेंसी); बाकी को फ़ाइल में संग्रहीत किया गया और मांग पर पढ़ा गया, उनके बैकिंग मेमोरी बफ़र्स को निष्पादन के पश्चात् जारी किया गया।
संस्करण 3.0 में टीपीएफ में सी (प्रोग्रामिंग भाषा) का परिचय पहली बार लोडर सम्मेलनों के अनुरूप क्रियान्वित किया गया था, जिसमें लिंकेज संपादन की अनुपस्थिति भी सम्मिलित थी। इस योजना ने शीघ्र ही स्वयं को सबसे सरल सी प्रोग्राम के अतिरिक्त किसी अन्य चीज़ के लिए अव्यावहारिक सिद्ध करना कर दिया। टीपीएफ 4.1 में, सही मायने में और पूरी तरह से लिंक किए गए लोड मॉड्यूल को टीपीएफ से प्रस्तुतकिया गया था। इन्हें TPF-विशिष्ट हेडर फ़ाइलें का उपयोग करके z/OS C/C++ कंपाइलर के साथ संकलित किया गया और IEWL के साथ जोड़ा गया, जिसके परिणामस्वरूप z/OS-अनुरूप लोड मॉड्यूल प्राप्त हुआ, जिसे किसी भी तरह से पारंपरिक TPF लोडर नहीं माना जा सकता है। टीपीएफ लोडर को z/OS-अद्वितीय लोड मॉड्यूल फ़ाइल प्रारूप को पढ़ने के लिए बढ़ाया गया था, फिर फ़ाइल-निवासी लोड मॉड्यूल के अनुभागों को मेमोरी में ले जाया गया; इस मध्य, असेंबली भाषा कार्यक्रम टीपीएफ के सेगमेंट मॉडल तक ही सीमित रहे, जिससे असेंबलर में लिखे गए अनुप्रयोगों और उच्च स्तरीय भाषाओं (एचएलएल) में लिखे गए अनुप्रयोगों के मध्य स्पष्ट असमानता उत्पन्न हुई।
z/TPF 1.1 पर, सभी स्रोत भाषा प्रकार वैचारिक रूप से एकीकृत थे और निष्पादन योग्य और लिंकिंग प्रारूप विनिर्देश के अनुरूप पूरी तरह से लिंक-संपादित थे। सेगमेंट अवधारणा अप्रचलित हो गई, जिसका अर्थ है कि किसी भी स्रोत भाषा में लिखा गया कोई भी प्रोग्राम - जिसमें असेंबलर भी सम्मिलित है - वर्तमान किसी भी आकार का हो सकता है। इसके अतिरिक्त, बाहरी संदर्भ संभव हो गए, और भिन्न-भिन्न स्रोत कोड प्रोग्राम जो कभी सेगमेंट थे, वर्तमान सीधे साझा ऑब्जेक्ट में साथ जोड़े जा सकते हैं। मूल्य बिंदु यह है कि महत्वपूर्ण विरासत अनुप्रयोग सरल रीपैकेजिंग के माध्यम से उत्तम दक्षता से लाभ उठा सकते हैं - एकल साझा ऑब्जेक्ट मॉड्यूल के सदस्यों के मध्य किए गए कॉल में वर्तमान सिस्टम की ENTER/BACK सेवा को कॉल करने की तुलना में रन टाइम पर बहुत कम पथलंबाई होती है। समान साझा ऑब्जेक्ट के सदस्य वर्तमान लिखने योग्य डेटा क्षेत्रों को सीधे z/TPF 1.1 पर प्रारंभ की गई लिखने पर नकल कार्यक्षमता के कारण साझा कर सकते हैं; जो संयोगवश टीपीएफ की पुनर्प्रवेश (कंप्यूटिंग) आवश्यकताओं को पुष्ट करता है।
फ़ाइल- और मेमोरी-रेजीडेंसी की अवधारणाओं को भी z/TPF डिज़ाइन बिंदु के कारण अप्रचलित बना दिया गया था, जिसमें सभी प्रोग्रामों को हर समय मेमोरी में रेजिडेंट रखने की मांग की गई थी।
चूँकि z/TPF को उच्च-स्तरीय भाषा कार्यक्रमों के लिए कॉल स्टैक बनाए रखना था, जिससे HLL प्रोग्रामों को स्टैक-आधारित मेमोरी आवंटन से लाभ उठाने की क्षमता मिलती थी, वैकल्पिक आधार पर कॉल स्टैक को असेंबली भाषा प्रोग्रामों तक विस्तारित करना फायदेमंद माना गया, जो मेमोरी दबाव को कम कर सकता है और रिकर्सन (कंप्यूटर विज्ञान) प्रोग्रामिंग को आसान बना सकता है।
सभी z/TPF निष्पादन योग्य प्रोग्राम वर्तमान ELF साझा ऑब्जेक्ट के रूप में पैक किए गए हैं।
मेमोरी उपयोग
ऐतिहासिक रूप से और पिछले के साथ कदम में, कोर ब्लॉक- मेमोरी- भी आकार में 381, 1055 और 4 K बाइट्स थे। चूँकि सभी मेमोरी ब्लॉक इस आकार के होने चाहिए थे, इसलिए अन्य प्रणालियों में मिलने वाली मेमोरी प्राप्त करने के लिए अधिकांश ओवरहेड को छोड़ दिया गया था। प्रोग्रामर को केवल यह तय करने की आवश्यकता थी कि किस आकार का ब्लॉक आवश्यकता के अनुरूप होगा और इसके लिए पूछें। टीपीएफ उपयोग में आने वाले ब्लॉकों की सूची बनाए रखेगा और उपलब्ध सूची में पहला ब्लॉक सौंप देगा।
भौतिक मेमोरी को प्रत्येक आकार के लिए आरक्षित अनुभागों में विभाजित किया गया था, इसलिए 1055 बाइट ब्लॉक सदैव अनुभाग से आता था और वहां लौटता था, केवल ओवरहेड की आवश्यकता थी कि उसका पता उचित भौतिक ब्लॉक तालिका की सूची में जोड़ा जाए। किसी संघनन या डेटा संग्रह की आवश्यकता नहीं थी।
जैसे-जैसे एप्लिकेशन अधिक उन्नत होते गए, मेमोरी की मांग बढ़ती गई, और बार सी उपलब्ध होने के पश्चात् अनिश्चित या बड़े आकार के मेमोरी खंडों की आवश्यकता होने लगी। इसने हीप स्टोरेज और कुछ मेमोरी प्रबंधन रूटीन के उपयोग को जन्म दिया। ओवरहेड को कम करने के लिए, टीपीएफ मेमोरी को फ्रेम में तोड़ दिया गया था - आकार में 4 केबी (जेड/टीपीएफ के साथ 1 एमबी)। यदि किसी एप्लिकेशन को निश्चित संख्या में बाइट्स की आवश्यकता होती है, तब उस आवश्यकता को पूरा करने के लिए आवश्यक सन्निहित फ़्रेमों की संख्या प्रदान की जाती है।
संदर्भ
- ↑ Template:उद्धरण वेब
- ↑ 2.0 2.1 Steve Lohr (October 4, 2004). "IBM Updates Old Workhorse to Use Linux". The New York Times.
- ↑ Michelle Louzoun (August 24, 1987). "Visa Is Everywhere It Wants To Be". InformationWeek. p. 19.
- ↑ IBM Corporation. "टीपीएफ डेटाबेस सुविधा (टीपीएफडीएफ)". z/Transaction Processing Facility. Retrieved November 11, 2016.
- ↑ "IBM bolsters its mainframe platform". Computerworld.
- ↑ Jennifer Mears. "IBM pumps up Linux virtual machines on mainframe OS". Computerworld.
- ↑ "टीपीएफ उपयोगकर्ता समूह, जॉब कॉर्नर". Archived from the original on 2000-01-15.
- ↑ "IBM News room - 2008-04-14 Japan Airlines International to Upgrade Reservation and Ticketing System With IBM Mainframe - United States". 03.ibm.com. 2008-04-14. Retrieved 2017-03-15.
- ↑ Anne & Lynn Wheeler. "IBM 9020 computers used by FAA (was Re: EPO stories (was: HELP IT'S HOT!!!!!))". Newsgroup: alt.folklore.computers.
- ↑ "आईबीएम नॉलेज सेंटर". Publib.boulder.ibm.com. 2014-10-24. Retrieved 2017-03-15.
- ↑ "IBM z/Transaction Processing Facility Enterprise Edition V1.1 hardware requirements - United States". www-01.ibm.com. Archived from the original on 7 October 2012. Retrieved 17 January 2022.
- ↑ IBM Corporation (19 Apr 2018). "z/TPF Glossary". IBM. Retrieved 10 May 2018.
- ↑ IBM Corporation (19 April 2018). "आईबीएम टीपीएफ ऑपरेशंस सर्वर". IBM. Retrieved 10 May 2018.
- ↑ IBM Corporation (29 January 2019). "z/TPF Operations Command Guide". IBM.
- ↑ Bedford Associates. "बेडफोर्ड एसोसिएट्स, इंक". Retrieved October 17, 2012.
- ↑ TPF Software. "टीपीएफ सॉफ्टवेयर, इंक". Retrieved October 17, 2012.
- ↑ IBM Corporation (Dec 2017). "आईबीएम टीपीएफ टूलकिट अवलोकन". IBM. Retrieved 10 May 2018.
ग्रन्थसूची
- ट्रांजेक्शन प्रोसेसिंग सुविधा: एप्लिकेशन प्रोग्रामर्स के लिए एक गाइड (योर्डन प्रेस कंप्यूटिंग सीरीज़) आर. जेसन मार्टिन द्वारा (हार्डकवर - अप्रैल 1990), ISBN 978-0139281105
बाहरी संबंध
- जेड/टीपीएफ (आईबीएम)
- टीपीएफ उपयोगकर्ता समूह (टीपीएफ उपयोगकर्ता समूह)
