الخلاصة

  • اقترح RFC 1041 خيارًا واحدًا باسم 3270-REGIME، لكن RFC 1576 قال إن عددًا قليلًا جدًا من المطورين والموردين نفّذه. قامت الممارسة الفعلية على Terminal-Type وBinary وEOR منفصلة.
  • أثبتت الخيارات شكل المحاكاة وطريق الثمانيات وحد الكتلة، ولم توفر اسم جهاز/LU محددًا أو صورة BIND في SNA أو رد معالجة مترابطًا أو معنى موحدًا لـATTN وSYSREQ.
  • أضاف TN3270E لاحقًا اسم الجهاز وBIND-IMAGE وRESPONSES كوظائف مستقلة قابلة للتفاوض. لم يثبت اسم الخيار وحده تفعيلها أو هوية المستخدم أو النتيجة النهائية.

كانت هناك مواصفة للانتقال، ولم تصبح هي الطريق الغالب

لم يكن 3270 طرفية محارف عادية. استعمل EBCDIC وتبادل أوامر وبيانات في كتل كاملة. لذلك احتاج نقله عبر Telnet إلى اتفاق على نوع الطرفية، ونقل ثماني البتات، وعلامة تفصل نهاية كل كتلة.

جمع RFC 1041 هذه العناصر سنة 1988 في الخيار 29، 3270-REGIME. يعرض العميل قائمة مرتبة من الأنماط، ويختار الخادم ما يستطيع الطرفان تشغيله. كان اختيار 3270 يتضمن معنى Binary وIAC EOR، وكانت القائمة الفارغة تعيد الطرفين إلى NVT ASCII.

ركز النص على لحظة التحول. ينبغي للعميل وقف إدخال المستخدم أثناء التفاوض، وللخادم تجنب إرسال بيانات جديدة وإفراغ ما بقي قبل إعلان النمط. يبدل الخادم مفسره عند إرسال الاختيار، ويبدله العميل عند استلامه؛ وقد يلزم إفراغ المخازن في الاتجاهين. فالبيانات الصحيحة تصبح خطأ إذا قرأتها قواعد النمط الآخر.

لكن وضوح التصميم لم ينشئ تبنيًا واسعًا. قال RFC 1576 في 1994 إن عددًا قليلًا جدًا من المطورين والموردين نفّذ RFC 1041. وتوضح صفحة RFC Editor أنه وثيقة Informational. ليست العبارة إحصاءً لكل المنتجات ولا تعني انعدام التنفيذ، لكنها تبرر توثيق الاتفاق الذي كان يعمل بالفعل.

صنع التراكم نمطًا من ثلاثة أجزاء

اعتمد TN3270 التقليدي على Telnet ثم تفاوض على Terminal-Type وBinary Transmission وEnd of Record. يطلب الخادم نوع المحاكاة ويجيب العميل؛ يحفظ Binary الثمانيات؛ وتنهي IAC EOR الأمر الكامل.

لم يقل أي خيار بمفرده إن جلسة TN3270 قامت. كوّن اجتماع الحالات الثلاث المعيار الفعلي. لم يشترط RFC 1576 ترتيبًا معينًا. وبعد اكتمال النوع الملائم وBinary وEOR، تبادل الطرفان كتل 3270. وإذا سحب الخادم Binary أو EOR، لم تعد الجلسة صالحة لـTN3270، وصار على العميل تفسير البيانات التالية بوصفها NVT ASCII.

نجح العقد لأنه بقي ضيقًا. Binary يحدد معاملة الثمانيات، وEOR يحدد نهاية كتلة، وTerminal-Type يحدد العرض. أما الخادم فاحتفظ بقرار وصل الواجهة بتطبيق مركزي عبر SNA أو طريق آخر.

استطاعت الشاشة أن تعمل من دون اسم LU

كان Terminal-Type غير متماثل. يسأل الخادم، ويعرض العميل الأنواع بالتتابع. قد يغير العميل محاكاته حين يرسل اسمًا جديدًا، لكن استلام الخادم للاسم لا يفرض عليه تغيير المعالجة فورًا.

لهذا وصف اسم طراز 3278 خصائص شاشة، لا جهازًا ماديًا ولا مستخدمًا ولا Logical Unit خلف البوابة. وكانت اللاحقة -E تشير عادة إلى structured fields، فيما استنتجت منها بعض الخوادم قدرات إضافية. لم تكن شهادة كاملة للقدرات.

في SNA، امتلكت الطرفية عادة جلسة مع التطبيق وأخرى مع System Services Control Point. رأى عميل TN3270 اتصال Telnet واحدًا. لم تكن لديه آلية معيارية لطلب device-name بعينه أو معرفة LU name الذي خصصه الخادم على جانب SNA.

وصف RFC 1576 عنوان IP للعميل بأنه أقرب شيء إلى LU name في هذه البيئة. تكشف كلمة «أقرب» الفرق: عنوان IP يحدد طرف الشبكة، أما LU فيحدد موردًا منطقيًا قد يغيّر تطبيق المضيف سلوكه تبعًا لاسمه.

نهاية السجل ليست نهاية المعالجة

لم تحمل كتلة 3270 طولًا خارجيًا في TN3270 التقليدي، لذلك كانت EOR حاسمة. تعني IAC EOR أن الأمر اكتمل ويمكن بدء تفسيره. لا تعني نجاح التفسير أو التنفيذ.

عدّ RFC 1576 الردود الموجبة والسالبة في SNA من الوظائف الناقصة. يشير الرد الموجب إلى اكتمال معالجة البيانات السابقة، وقد يكشف الرد السالب أمرًا غير صالح أو عطلًا ميكانيكيًا عند العميل. لم يحمل TN3270 التقليدي هذا الإيصال؛ اعتُبرت البيانات إما معالجة أو متجاهلة.

إذن استلام TCP، وحفظ Binary، ووصول EOR، وقبول الأمر، وتغير الشاشة، وعمل الطابعة، واستجابة التطبيق، وانتباه الشخص أحداث مستقلة.

كما أن NOP أو Timing Mark لا يغلق السلسلة. يمكنهما اختبار بقاء العميل؛ لا يطلب NOP جوابًا من التطبيق، وقد لا يظهر موت العميل إلا كخطأ إرسال TCP. بقاء العملية لا يثبت صحة التطبيق أو حضور المستخدم.

كشفت ATTN وSYSREQ سلطة الترجمة المحلية

استُعمل ATTN لطلب مقاطعة العمل الجاري. ربطه كثير من العملاء بأمر Telnet BREAK، ثم ترجم الخادم الأمر نحو SNA. ويمكن لخادم غير SNA تجاهله.

اختلف SYSREQ أكثر. فسرت خوادم Telnet Interrupt Process على أنه SYSREQ، واستعملت أخرى 3270 Test Request. في SNA يمكنه التحويل بين جلسة التطبيق وجلسة SSCP. ولأن تنسيق SSCP لم يعبر مباشرة إلى العميل، كان على الخادم معالجته أو تحويله أو ترك الوظيفة.

ضغطة المفتاح، وأمر Telnet، وترجمة الخادم، وحدث SNA، ومقاطعة التطبيق تحتاج إلى سجلات منفصلة. لا تمنح الأولى دليلًا على الأخيرة.

أعاد TN3270E بناء سجل متعدد الطبقات

قدمت RFC 1646 وRFC 1647 امتدادات مبكرة. ثم جمع RFC 2355، المثبت في سجله الرسمي على Standards Track سنة 1998، وظائف TN3270E.

بدأ التفاوض بنوع الجهاز، ومعه اختياريًا مورد أو device-name. يعيد الخادم الاسم الذي خصصه، أو يرفض بسبب اسم مجهول أو جهاز مشغول أو عدم توافق النوع والاسم. بعد ذلك تأتي قائمة FUNCTIONS.

تبلغ BIND-IMAGE العميل ببدء جلسة SNA مع التطبيق وانتهائها. وتضيف RESPONSES رأسًا وسياسة رد ورقم تسلسل لربط النتيجة الموجبة أو السالبة بالكتلة الصحيحة. بقي SYSREQ ودعم الطابعة وظيفتين مستقلتين. ويمكن أن تكون القائمة فارغة، وهو basic TN3270E.

ظل للصمت أكثر من معنى: بلا رد، أو رد عند الخطأ فقط، أو رد دائم. إذا لم تُتفاوض RESPONSES فلا يمثل رقم التسلسل إيصالًا. ومن دون BIND-IMAGE لا يكشف TN3270E وحده حالة BIND. وإذا رفض طرف الخيار أمكن الرجوع إلى TN3270 التقليدي.

ونص RFC 2355 على أن الامتدادات لا تضيف أمنًا إلى Telnet العادي. تخصيص device-name لا يثبت أن المستخدم مخول باستعماله.

الكود العامل دليل أولي لا سلطة كاملة

يوضح RFC 1041 نظافة رسمية لم تنتشر، ويوضح TN3270 التقليدي توافقًا عاملًا بإيصالات ناقصة، ثم يوضح TN3270E كيف تضاف الوقائع منفصلة مع بقاء الرجوع ممكنًا.

يوجه نص Heng Lu عن أولوية الكود العامل البحث إلى النظام الذي نفذ الفعل. ويشرح الحد الأدنى المشترك والقرار المحلي قيمة تركيب صغير يمكن تبنيه. وتمنع طبقات الواقع دمج العرض والجلسة والهوية والنتيجة. هذه عدسة تحريرية لاحقة، لا نسبة لمقاصد مؤلفي RFC.

جعلت ثلاثة خيارات الطرفية قابلة للاستخدام. سمّى Terminal-Type المحاكاة، وحفظ Binary الثمانيات، وأغلق EOR الكتلة. بقي LU وBIND والمعالجة والمقاطعة والنتيجة بحاجة إلى دليل خاص بكل منها.

المصادر