RFC1646 日本語訳
1646 TN3270 Extensions for LUname and Printer Selection. C. Graves, T.Butts, M. Angel. July 1994. (Format: TXT=27564 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group C. Graves
Request for Comments: 1646 T. Butts
Category: Informational M. Angel
Open Connect Systems
July 1994
墓がコメントのために要求するワーキンググループC.をネットワークでつないでください: 1646 T.はカテゴリを接合します: オープンな情報のM.天使はシステム1994年7月に接続します。
TN3270 Extensions for LUname and Printer Selection
LUnameのためのTN3270拡張子とプリンタ選択
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Abstract
要約
This document describes protocol extensions to TN3270. There are two extensions outlined in this document. The first defines a way by which a TN3270 client can request a specific device (LUname) from a TN3270 server. The second extension specifies how a TN3270 printer device can be requested by a TN3270 client and the manner in which the 3270 printer status information can be sent to the TN3270 server. Discussions and suggestions for improvements to these enhancements should be sent to the TN3270E Working Group mailing list TN3270E@list.nih.gov . These extensions will be called TN3287 in this document. This information is being provided to members of the Internet community that want to support the 3287 data stream within the TELNET protocol.
このドキュメントはプロトコル拡大についてTN3270に説明します。 本書では概説された2つの拡大があります。 1番目はTN3270クライアントがTN3270サーバから特定のデバイス(LUname)を要求できる方法を定義します。2番目の拡大は3270年のプリンタ状態情報をTN3270サーバに送ることができるTN3270クライアントと方法でどうTN3270プリンタデバイスを要求できるかを指定します。これらの増進への改良のための議論と提案をTN3270E作業部会メーリングリスト TN3270E@list.nih.gov に送るべきです。本書ではこれらの拡大をTN3287と呼ぶでしょう。 TELNETプロトコルの中で3287年のデータ・ストリームをサポートしたがっているインターネットコミュニティのメンバーにこの情報を提供しています。
1. INTRODUCTION
1. 序論
The need to communicate with IBM mainframe systems has a number of unique requirements associated with it. This document addresses those needs in a TCP/IP communications network.
IBMメインフレームシステムとコミュニケートする必要には、それに関連している多くのユニークな要件があります。 このドキュメントはTCP/IP通信網でそれらの必要性を扱います。
IBM terminals are generically referred to as 3270's which includes a broad range of terminals and devices,not all of which actually begin with the numbers 327x.
IBM端末は一般的に広範囲な端末を含んで、すべてではなく、それのデバイスが実際に数の327xで始まる3270年代と呼ばれます。
The 3270 family of terminals and the IBM mainframe applications systems are VERY closely coupled and it is the nature of the way the 3270s and the applications interact which require that this document be available to provide a consistent way for the TCP/IP environment to interact effectively with the 3270 applications of the IBM mainframe world.
3270年の端末のファミリーとIBMメインフレームアプリケーションシステムは非常に密接に結合されます、そして、それはこのドキュメントが有効に3270年のIBMメインフレーム世界のアプリケーションと対話するためにTCP/IP環境に一貫した道で備えるために利用可能であることを必要とする3270年代とアプリケーションが相互作用する方法の本質です。
Graves, Butts & Angel [Page 1] RFC 1646 TN3270 Extensions July 1994
墓、尻、および天使[1ページ]RFC1646TN3270拡大1994年7月
IBM mainframe applications systems have existed for almost two decades now and are used to serve tens of thousands of users daily. For this reason it is usually the need of a mainframe environment to add TCP/IP network support WITHOUT writing new applications to run with the TCP network. The TN3270 series of documents addresses how this can be done and maintain compatibility with those mainframe application systems.
IBMメインフレームアプリケーションシステムは、現在、およそ20年間の間、存在して、毎日何万人ものユーザに役立つのに使用されます。 この理由で、通常、それはTCPネットワークと共に実行する新しいアプリケーションを書きながらTCP/IPネットワークサポートWITHOUTを加えるメインフレーム環境の必要性です。 ドキュメントのTN3270シリーズはこれがそれらのメインフレームアプリケーション・システムでどうして、互換性を維持できるかを扱います。
One of the unique characteristics of the 3270 terminals is their ability to communicate status information in an out-of-band data flow. These status's are in turn used by the applications systems to support error recovery, and conflict resolutions, examples of these are printer out of paper, and terminal powered up. The terminals are also half duplex and block mode in their operations, which results in the need to communicate when blocks are being sent, when they end, and when they cannot be sent. This document describes these characteristics in IBM VTAM/SNA terms. Some VM mainframe application systems do not use VTAM, so for those systems these terms don't apply. For any systems which use VTAM these terms apply and are dealt with in some way by the TCP/IP to VTAM interface.
3270台の端末のユニークな特性の1つはバンドで出ているデータフローの状態情報を伝える彼らの能力です。 状態のこれらのものsはアプリケーションシステムによって順番に使用されて、エラー回復、および紛争解決をサポートした、これらに関する例は紙からのプリンタです、そして、端末はエネルギー消費量を上げました。 端末は、彼らの操作で半二重ともブロックモードです。(そのモードはいつブロックを送るか、そして、それらがいつ終わるか、そして、いつそれらは送ることができないかを伝える必要性をもたらします)。 このドキュメントはIBM VTAM/SNA用語でこれらの特性について説明します。いくつかのVMメインフレームアプリケーション・システムはVTAMを使用しません、したがって、これらの用語がそうしないそれらのシステムには、申し込んでください。 VTAMを使用するどんなシステムにおいても、これらの用語は、適用して、TCP/IPによってVTAMインタフェースに何らかの方法で対処されています。
VTAM/SNA is a hierarchical network and some of that hierarchy needs to be addressed by the TCP network attaching to it if the applications systems are to continue to provide the same applications support that they have provided to the 3270 terminals.
VTAM/SNAは階層的なネットワークです、そして、その階層構造のいくつかがアプリケーションシステムがそれらが3270台の端末に供給したのと同じアプリケーションサポートを提供し続けることであるならそれに付くTCPネットワークによって扱われる必要があります。
The 3270 terminal environment consists of a terminal controller with terminals attached to that controller. In VTAM/SNA this controller is called a PU (Physical Unit) and the terminals called LUs (Logical Units). The PU is used to communicate management information to the VTAM/SNA system, and the LU is used by the application to communicate with the terminal. VTAM/SNA identifies each LU and PU in a network by a unique name. These names are referred to as LUnames and PUnames, and is how the network is managed and the applications identify what terminals are being communicated with in the network. The actual connection between a terminal and the applications is referred to as a session, and it is this session which has both in- band and out-of-band information flows sent between the applications and the terminals.
3270年の端末の環境は端末がそのコントローラに愛着している端末制御装置から成ります。 VTAM/SNAで、このコントローラはPU(物理的なUnit)とLUsと呼ばれる端末(論理的なUnits)と呼ばれます。 PUはVTAM/SNAシステムに経営情報を伝えるのに使用されます、そして、LUは、端末で交信するのにアプリケーションで使用されます。 VTAM/SNAはユニークな名前のネットワークで各LUとPUを特定します。 これらの名前は、LUnamesとPUnamesと呼ばれて、ネットワークがどう経営されるかということです、そして、アプリケーションはどんな端末がネットワークでコミュニケートされているかを特定します。 端末とアプリケーションとの実際の関係はセッションと呼ばれます、そして、それはアプリケーションの間に送られたコネバンドとバンドのアウト情報流れと端末の両方があるこのセッションです。
VTAM/SNA 3270 terminals actually have two sessions when communicating with the applications. One session is directly connected with the application and the other session is connected directly to VTAM. It is the session with VTAM, also called the SSCP, that is used to communicate the out-of-band information flows. This session is called the SSCP-LU session, and the session with the application is called the LU-LU session (in VTAM an applications is just another Logical Unit).
アプリケーションとコミュニケートするとき、VTAM/SNA3270台の端末には、2つのセッションが実際にあります。 1つのセッションが直接アプリケーションに接続されます、そして、もう片方のセッションは直接VTAMに接続されます。 バンドで出ている情報流れを伝えるのに使用されるのは、また、SSCPと呼ばれるVTAMとのセッションです。 このセッションはSSCP-LUセッションと呼ばれます、そして、アプリケーションとのセッションはLU-LUセッションと呼ばれます(VTAMでは、アプリケーションはただのLogical Unitです)。
Graves, Butts & Angel [Page 2] RFC 1646 TN3270 Extensions July 1994
墓、尻、および天使[2ページ]RFC1646TN3270拡大1994年7月
One such out-of-band flow is the LUSTAT message which tells the application that the status of the terminal has changed, and is how a printer or screen tells the application that it is ready, or is not ready to receive data.
そのような流れのバンドで出ている1つは、端末の状態が変化したとアプリケーションに言うLUSTATメッセージであり、プリンタかスクリーンが、それを準備ができているか、またはデータを受け取る準備ができていないとどうアプリケーションに言うかということです。
There are also flows which must be able to flow in the LU-LU session to help control the use of the terminal by applications. The block of information sent in a session is called an RU (Request Unit) and it tells what type of data this block contains, how long it is and if more data (RUs) is coming along. This is a gross over simplification of what RUs are and do, but it should help understand their use in the TN3270 documents. Some of the VTAM/SNA terms used to describe what an RU is requesting are: Chains/chaining which tell a session partner that another RU is being sent or not being sent in this transmission. Brackets which are used to indicate that a unit of work is complete, such as when a printout of a file is complete.
LU-LUセッションのときに端末のアプリケーションによる使用を制御するのを助けるために流れることができなければならない流れもあります。 情報のブロックは、セッションがRUと呼ばれるのを(Unitを要求してください)送りました、そして、それはこのブロックがどんなタイプに関するデータを含んでいるか、そして、それがどれくらい長いか、そして、より多くのデータ(RUs)がやって来ているかどうか言います。 これはRUsが何であるかに関する簡素化の上のグロスです、そして、しなさい、ただし、それはTN3270ドキュメントにおける彼らの使用を理解しているのを助けるべきです。 RUが要求していることについて説明するのに使用されるVTAM/SNA用語のいくつかは以下の通りです。 別のRUを送るか、またはこのトランスミッションで送らないとセッションパートナーに言うチェインズ/推論。 ファイルのプリントアウトが完全である時のように仕事のユニットが完全であることを示すのに使用される括弧。
The determination of what part of the VTAM/SNA protocols such as brackets and chaining are to be used are managed by VTAM tables called LOGMODE tables. These tables are selected when an LU-LU session is started and set up such things as bracket, and/or chaining protocols; and the type of terminal data contained in the RUs, such as printer data without screen formatting data (LU type 1), 3270 screen formatted data (LU type 2) and 3270 screen formatted data for a printer (LU type 3). The LOGMODE tables also contain the size of the RU to be sent and received. These tables also communicate the screen size of 3270 terminals such as 24X80 (Model 2), 27X132 (Model 5), etc. Each LU has a LOGMODE table entry hard assigned to it as part of the VTAM configuration (often called a GEN). The selection of these table entries can't be controlled by the terminal LU or PU. They can only be selected by the user at connection/logon time or by the application when the connection is established. The actual LOGMODE entries to be used during a session are sent at session logon time, in a special type of RU called a BIND. Once the bind has been sent then the rules for the use of the session have been set, can't be changed, and must be followed.
使用されて、括弧と推論がものであるVTAM/SNAプロトコルのどんな部分がVTAMによって管理されるかに関する決断は呼ばれたLOGMODEテーブルをテーブルの上に置きます。 これらのテーブルは、LU-LUセッションが始められるとき、選択されて、ブラケットのようなもの、そして/または、推論プロトコルをセットアップします。 そして、スクリーン形式データ(LUは1をタイプする)のないプリンタデータなどのRUsに含まれた端末のデータのタイプ、3270スクリーンはデータをフォーマットしました、そして、(LUは2をタイプします)3270スクリーンはプリンタのためのデータをフォーマットしました(LUは3をタイプします)。 LOGMODEテーブルは、また、送られるRUのサイズを含んで、受信されました。 また、これらのテーブルは24×80(モデル2)、27×132(モデル5)などの3270台の端末の画面サイズを伝えます。 各LUはLOGMODEにVTAM構成の一部としてそれに割り当てられた状態で(しばしばGENと呼ばれた)エントリーを一生懸命テーブルの上に置かせます。 端末のLUかPUがこれらのテーブル項目の品揃えを制御できません。 接続が確立されるときだけ、接続/ログオン時のユーザかアプリケーションでそれらを選択できます。 セッションログオン時間にセッションの間に使用されるべき実際のLOGMODEエントリーを送ります、BINDと呼ばれるRUの特別なタイプで。 一度、ひもを送ったことがあって、次に、セッションの使用のための規則を設定されて、変えることができないで、従わなければなりません。
The purpose of the TN3287 protocol is to provide a general IBM 3270 host printer communications facility. Its primary goal is to allow a method of connecting printer devices and printer-oriented processes to each other. This protocol will allow a TN3270 Client to process 3287 print data streams.
TN3287プロトコルの目的は一般的なIBM3270ホストプリンタコミュニケーション施設を提供することです。 プライマリ目標はプリンタデバイスとプリンタ指向のプロセスを互いに接続するメソッドを許容することです。 このプロトコルで、TN3270 Clientは3287の印刷データ・ストリームを処理できるでしょう。
This memo supplements and extends the STD 8, RFC 854, TELNET Protocol Specification. This memo also presents an example of the correct implementation.
TELNETプロトコルSpecification、このメモはSTD8、RFC854を補って、広げています。 また、このメモは正しい実装に関する例を提示します。
Graves, Butts & Angel [Page 3] RFC 1646 TN3270 Extensions July 1994
墓、尻、および天使[3ページ]RFC1646TN3270拡大1994年7月
2. GENERAL CONSIDERATIONS
2. 一般的な問題
A TELNET connection is a Transmission Control Protocol (TCP) connection used to transmit data with interspersed TELNET control information.
TELNET接続は点在しているTELNET制御情報でデータを送るのに使用される通信制御プロトコル(TCP)接続です。
The companion document, STD 8, RFC 854 -- "TELNET Protocol Specification" should be consulted for further information about the TELNET command, codes and code sequences referenced in this specification.
仲間ドキュメント、STD8、RFC854--「telnetプロトコル仕様」はTELNETコマンド、コード、およびコード系列に関する詳細のためにこの仕様で参照をつけられた状態で相談されるべきです。
3. CLIENT-SERVER NEGOTIATION
3. クライアント/サーバ交渉
The TN3270 Client and Server require a specific negotiation protocol. After the negotiation is complete, all transmission between the Client and Server is in TELNET Binary format with a TELNET "End-Of- Record(EOR)" sequence at the end of each data stream.
TN3270 ClientとServerは特定の交渉プロトコルを必要とします。 交渉が完全になった後に、TELNET Binary形式にはClientとServerの間のすべてのトランスミッションがTELNETと共にある、「-記録(EOR)では、」 それぞれのデータの終わりの系列が流れる終わり。
Support for the TN3287 data stream requires that both sides:
TN3287データ・ストリームのサポートはその両側を必要とします:
A. Are able to exchange binary data.
A.はバイナリ・データを交換できます。
B. Can establish the agreement between client and server on the
terminal type that will be used.
B. 使用される端末のタイプの上でクライアントとサーバとの協定を確立できます。
C. Agree to use the TELNET IAC EOR as a delimiter for inbound
and outbound TN3287 data streams
C. 本国行きの、そして、外国行きのTN3287データのためのデリミタが流れるときTELNET IAC EORを使用するのに同意してください。
This implementation requires the options: TERMINAL-TYPE and BINARY be successfully negotiated between the Client and Server before processing of any print data streams.
この実装はオプションを必要とします: Clientの間で交渉されて、TERMINAL-TYPEとBINARYは首尾よくそうです、そして、どんな印刷データの処理の前のServerも流れます。
This implementation supports host applications that can mix LU 1 and LU 3 type data in the data stream.
この実装は、データ・ストリームでLU1を混ぜることができるホストアプリケーションとLU3がタイプデータであるとサポートします。
3.1 TN3287 SERVER
3.1 TN3287サーバ
The maximum Request Unit (RU) size is server specific, but should not exceed 4 kilobytes.
最大のRequest Unit(RU)サイズは、サーバ特有ですが、4キロバイトを超えるべきではありません。
The LU type is determined by the bind from the mainframe application. The server, when bound, must remember LU 1 or LU 3 type.
LUタイプはメインフレームアプリケーションからひもで決定します。 縛られると、サーバは、LU1かLU3がタイプするのを覚えていなければなりません。
The server will automatically unbind the session upon receipt of a TELNET CLOSE command. The printer will be reported to VTAM as powered down until a new TELNET connection is established.
サーバはTELNET CLOSEコマンドを受け取り次第自動的にセッションを解くでしょう。 プリンタは新しいTELNET接続が確立されるまでパワーダウンされるようにVTAMに報告されるでしょう。
Graves, Butts & Angel [Page 4] RFC 1646 TN3270 Extensions July 1994
墓、尻、および天使[4ページ]RFC1646TN3270拡大1994年7月
3.2 TN3287 CLIENT
3.2 TN3287クライアント
The TN3287 Client is a TN3270 client created specifically to print mainframe 3270 print data. The client emulates the IBM device type that it identifies itself to the TN3270 server as, in this case, an IBM 3287 model 1 type printer. The design of this printer protocol is aligned with the way printing occurs in the IBM host and how 3270 printers function. These printer extensions DO NOT support a 3270 printer client that cannot accept both types LU 1 and LU 3 printer streams. No IBM printer operates in this fashion, and as a result, no TN3270 server could function properly with mainframe applications if it didn't allow for a mixing of LU 1 and LU 3 data streams. The common way in which this can occur is printer sharing between multiple IBM host applications, such as CICS and JES. Since there is no restriction, the JES can be configured to output LU 1 data streams, and the CICS can be configured for LU 3 data streams. Therefore, the server will identify what LU type the current application connected to the server is using. If that type is LU 1, ALL message records sent to the Client will be preceded by one byte of binary zeros (0x00). If the first byte is not zeros, then that byte will be a valid LU type 3 Write-Command-Code(WCC), which can NEVER be zeros. Thus, the client can tell the LU type of data as each record is received.
TN3287 Clientは特にメインフレーム3270印刷データを印刷するために創造されたTN3270クライアントです。 IBM3287がこの場合1台のタイププリンタをモデル化するとき、クライアント自身はそれが特定するIBMの装置タイプをTN3270サーバに見習います。 このプリンタプロトコルのデザインは印刷がIBMのホストに現れる方法と3270台のプリンタがどう機能するかに並べられます。 これが起こることができる一般的な方法は複数のIBMホストアプリケーションを平等に割り当てるプリンタです、CICSやJESのように。これらのプリンタ拡大は両方のタイプを受け入れることができない3270年のプリンタクライアントにLU1とLU3プリンタストリームをサポートしません。IBMプリンタは全くこんなやり方で動作しません、そして、その結果、LU1とLU3データ・ストリームの混合を考慮しないなら、TN3270サーバは全くメインフレームアプリケーションで適切に機能できないでしょうに。 以来、制限が全くありません、そして、LU1データ・ストリームを出力するためにJESを構成できます、そして、LU3データ・ストリームのためにCICSは構成できます。したがって、サーバは、サーバに関連している現在のアプリケーションがどんなLUタイプを使用しているかを特定するでしょう。 そのタイプがLU1であるなら、1バイトの2進のゼロ(0×00)はClientに送られたすべてのメッセージ記録に先行するでしょう。 最初のバイトがゼロでないなら、そのバイトは有効なLUタイプ3Writeコマンドコードになるでしょう(WCC)。(そのコードはゼロであるはずがありません)。 したがって、それぞれの記録が受信されているとき、クライアントはデータのLUタイプに言うことができます。
This protocol does allow for the client to shutdown if the client does not wish to support both LU types. This is accomplished by detecting an invalid data type from the received record, and notifying the user that the mainframe application has sent LU type x print data and should be configured for LU type y printing.
クライアントが両方のLUタイプをサポートしたくないなら、このプロトコルは閉鎖にクライアントを考慮します。 これは、受信された記録からの無効のデータ型を検出して、メインフレームアプリケーションがLUタイプxに印刷データを送ったことをユーザに通知することによって達成されて、LUタイプy印刷のために構成されるべきです。
4. COMMAND STRUCTURE
4. 命令系統
1. All TELNET commands consist of at least a two-byte sequence:
the "Interpret-as-Command(IAC)" escape character followed by
the code for the command.
1. すべてのTELNETコマンドが少なくとも2バイトの系列から成ります: 「解釈コマンド(IAC)」拡張文字はコマンドのためにコードで従いました。
NOTE: Since the TELNET IAC character (255 decimal) is used as a delimiter (together with EOR) in the inbound and outbound data streams, a data byte within the data stream itself that has the same value as the IAC command is sent as two bytes (255, 255) and one byte is discarded.
以下に注意してください。 TELNET IACキャラクタ(255小数)がデリミタ(EORに伴う)として本国行きとアウトバウンドデータストリームに使用されるので、2としてIACコマンドをバイト(255、255)と1バイト送るとき同じくらいがそれ自体で評価するデータ・ストリームの中の1データ・バイトが捨てられます。
4.1 TELNET COMMANDS
4.1 telnetコマンド
Command meaning - WILL and DO commands are used to obtain and grant permission for the subsequent subnegotiation. Both sides must exchange WILL TERM-TYPE and DO TERM-TYPE before subnegotiation.
コマンド意味--ウィルとするコマンドは、その後の副交渉のために許可を得て、与えるのに使用されます。 両側は副交渉の前でWILL TERM-TYPEとDO TERM-TYPEを交換しなければなりません。
Graves, Butts & Angel [Page 5] RFC 1646 TN3270 Extensions July 1994
墓、尻、および天使[5ページ]RFC1646TN3270拡大1994年7月
The actual exchange of information is done within the option subcommand.
オプションサブコマンドの中で実際の情報交換をします。
<IAC DO TERMINAL-TYPE> Sender requests that the other party begin terminal-type sub-negotiation.
<IAC DO TERMINAL-TYPE>Senderは、もう片方のパーティーが端末のタイプサブ交渉を始めるよう要求します。
<IAC WILL TERMINAL-TYPE> Sender is willing to send terminal-type information in a subsequent sub-negotiation.
<IAC WILL TERMINAL-TYPE>Senderは、その後のサブ交渉における端末のタイプ情報を送っても構わないと思っています。
<IAC SB TERMINAL-TYPE SEND IAC SE> Sender requests the receiver to transmit his terminal-type.
<IAC SB TERMINAL-TYPE SEND IAC SE>Senderは、彼の端末のタイプを伝えるよう受信機に要求します。
<IAC SB TERM TYPE IS IBM-3287-1 IAC SE> Sender is stating the name of his terminal-type. The code for <IS> is 0. Optionally, a specific Logical Unit (LU) can be requested by using the TERMINAL- TYPE string below. If no LUname is specified, the first available 3287 LU is selected.
<IAC SB TERM TYPE IS IBM-3287-1IAC SE>Senderは彼の端末のタイプの名前を述べています。 <が>であるので、コードは0です。 任意に、以下でTERMINAL- TYPEストリングを使用することによって、特定のLogical Unit(LU)を要求できます。 LUnameが全く指定されないなら、最初の利用可能な3287LUは選択されます。
IAC SB TERM-TYPE IS IBM-3287-1 @ LUNAME IAC SE
IAC SB用語タイプはIBM-3287-1@LUNAME IAC SEです。
<IAC DO BINARY> Sender requests that sender of the data starts transmitting or confirms that the sender of data is expected to transmit characters that are to be interpreted as 8 bits of binary data by the receiver.
<IAC DO BINARY>Senderは、データの送付者が伝わり始めるよう要求するか、またはデータの送付者がバイナリ・データの8ビットとして受信機によって解釈されることになっているキャラクタを伝えると予想されると確認します。
<IAC WILL BINARY> Sender requests permission to begin transmitting, or confirms it will now begin transmitting binary data.
<IAC WILL BINARY>Senderは、伝わり始める許可を要求するか、または現在バイナリ・データを伝え始めると確認します。
An <EOR> is sent at the end of each SNA Request Unit (RU) end of chain, in either direction. The first byte following the <EOR> is a Write-Command-Code(WCC) for LU 3 data streams.
どちらの方向でもチェーンのそれぞれのSNA Request Unit(RU)端の端に<EOR>を送ります。 <EOR>に続く最初のバイトはLU3データ・ストリームのためのWriteコマンドコード(WCC)です。
An <AO> is sent at the end of the SNA RU and end of bracket. This signifies the end of the print output or file by the IBM host application and possibly a change of LU type.
ブラケットのSNA RUと端の端に<AO>を送ります。 これはIBMホストアプリケーションとことによるとLUタイプの変化でプリント出力かファイルの端を意味します。
4.2 COMMAND VALUES
4.2 コマンド値
TELNET COMMAND CODE
IAC Interpret as Command 255
DO 253
WILL 251
SB SuBnegotiation option 250
SE Subnegotiation End 240
TERMINAL-TYPE 24
SEND 1
IS 0
Command255が253ウィル251SB SuBnegotiationオプション250SE Subnegotiation End240TERMINAL-TYPE24SEND1をするとき、TELNET COMMAND CODE IAC Interpretは0歳です。
Graves, Butts & Angel [Page 6] RFC 1646 TN3270 Extensions July 1994
墓、尻、および天使[6ページ]RFC1646TN3270拡大1994年7月
EOR End-Of-Record 25
BINARY 0
AO Abort Output 245
IP Interrupt Process 244
AYT Are You There 246
BREAK 243
そこの25の2進の0AOアボート出力245IP中断プロセス244AYTがあなたである記録のEOR終わりの246休み243
NOTE: The above codes and code sequences have the indicated meaning only when immediately preceded by an "Interpret as Command (IAC)".
以下に注意してください。 上のコードとコード系列には、すぐに「解釈コマンド(IAC)」で先行されている場合にだけ、示された意味があります。
5. TN3270 Printer Status Message
5. TN3270プリンタステータスメッセージ
The status message can be sent at any time. It must be sent every time the TN3270 Server sends an End-of-Record(EOR) indicator to the TN3270 Client, or when a printing error occurs at the Client. The Printer Status Message is only sent by the TN3270 Client. Once the End-Of-Record IAC is processed, the TN3270 Client sends the status message to the server when it is ready to receive more print data.
いつでも、ステータスメッセージを送ることができます。 TN3270 Serverが記録のEnd(EOR)インディケータをTN3270 Clientに送るときはいつも、誤植がClientに起こるとき、それを送らなければなりません。 Printer Status MessageはTN3270 Clientによって送られるだけです。 それが、より多くの印刷データを受け取る準備ができているとき、記録のEnd IACがいったん処理されると、TN3270 Clientはステータスメッセージをサーバに送ります。
MESSAGE DESCRIPTION: SOH % R S1 S2 IAC EOR
メッセージ記述: SOH%R S1 S2 IAC、EOR
SOH = 0X01
% = 0X6C
R = 0XD9
S1 = Status/Sense Byte 0
S2 = Status/Sense Byte 1
IAC = Telnet IAC Character
EOR = Telnet EOR Character
状態/感覚バイト0 0×01SOH=%=0X6C R=0XD9 S1=S2は状態/感覚バイト1IAC=telnet IACキャラクターEOR=telnet EORキャラクターと等しいです。
5.1 Status/Sense Byte description
5.1 状態/感覚Byte記述
5.1.1. S/S Byte 0:
5.1.1. S/Sバイト0:
High Order Low Order
高位下位
_____________________________________________________________
| |
| 0 1 2 3 4 5 6 7 |
|___________________________________________________________|
_____________________________________________________________ | | | 0 1 2 3 4 5 6 7 | |___________________________________________________________|
Bit Number: Bit Definition:
噛み付いている数: 噛み付いている定義:
0 Always Zero
0 いつもゼロ
1 Always Zero
1 いつもゼロ
Graves, Butts & Angel [Page 7] RFC 1646 TN3270 Extensions July 1994
墓、尻、および天使[7ページ]RFC1646TN3270拡大1994年7月
2 Always Zero
2 いつもゼロ
3 Always Zero
3 いつもゼロ
4 Always Zero
4 いつもゼロ
5 Unit Specify - is set due to an error
condition. The reason for the error
condition will be indicated in S/S Byte 1.
See Note 1*.
5Specify--エラー条件のため設定されます。 エラー条件の理由はS/S Byte1で示されるでしょう。 注意1*を見てください。
6 Device End - when this bit sent in response
to a data message it indicates the client
has successfully processed the data message
from the server and notifies the server to
send a new data message to the client when
available. See Note 2*.
6 デバイスEnd--このビットがデータメッセージに対応して発信したとき、それは、クライアントがサーバからデータメッセージを首尾よく処理したのを示して、利用可能であるときに、サーバが新しいデータメッセージをクライアントに送るように通知します。 注意2*を見てください。
7 Always Zero
7 いつもゼロ
Note 1*: A negative response to the Server's data message would be S/S Byte 0 Bit 5 "Unit Specify condition". The possible Unit Specify conditions are listed below. (See Section 3.2 for bit settings for the Unit Specify conditions listed below.)
注意1*: Serverのデータメッセージへの否定応答はS Byte0Bit5S/「ユニットSpecify状態」でしょう。 可能なUnit Specify状態は以下にリストアップされています。 (以下にリストアップされたUnit Specify状態に関して噛み付いている設定にセクション3.2を見てください。)
Unit Specify Condition: SNA Sense Code sent to host:
ユニットは状態を指定します: SNA Sense Codeはホストに発信しました:
Command Rejected 0X10030000
Intervention Required 0X08020000
Data Check 0X10010000
Operation Check 0X10050000
Component Disconnected (LU) 0X08020000
コマンドは(Lu)0X08020000であると切断された0×10030000の介入の必要な0×08020000データ点検0X10010000動作チェック0X10050000コンポーネントを拒絶しました。
Note 2*: Device End - A positive response to the Server's data message would be the "Device End" bit (S/S Byte 0 Bit 6) to indicate a ready to receive data from the host condition. This will also be sent after clearing a previous Unit Specify condition of "Intervention Required".
注意2*: デバイスEnd--Serverのデータメッセージへの積極的な応答は、ホスト状態からデータを受け取る準備ができているaを示すためには「デバイスエンド」ビット(S/S Byte0Bit6)でしょう。 また、「介入が必要であること」を前のUnit Specify状態から取り除いた後に、これを送るでしょう。
Graves, Butts & Angel [Page 8] RFC 1646 TN3270 Extensions July 1994
墓、尻、および天使[8ページ]RFC1646TN3270拡大1994年7月
5.1.2. S/S Byte 1:
5.1.2. S/Sバイト1:
High Order Low Order
高位下位
______________________________________________________________
| |
| 0 1 2 3 4 5 6 7 |
|____________________________________________________________|
______________________________________________________________ | | | 0 1 2 3 4 5 6 7 | |____________________________________________________________|
Bit Number: Bit Definition:
噛み付いている数: 噛み付いている定義:
0 Always Zero
0 いつもゼロ
1 Always Zero
1 いつもゼロ
2 Command Rejected (CR) -- This bit
indicates an invalid 3270 command
generated.
2 コマンドRejected(CR)--このビットはコマンドが生成した無効の3270を示します。
3 Intervention Required - Printer Not Ready.
See Note 3*.
介入が必要とした3--プリンタは準備しません。 注意3*を見てください。
4 Component Disconnected - Printer is powered
off or printer cable not connected. See
Note 4*.
4 コンポーネントDisconnected--プリンタは接続されなかったオフであるかプリンタの動力付きのケーブルです。 注意4*を見てください。
5 Data Check - Invalid print data
5データCheck--無効の印刷データ
6 Always Zero
6 いつもゼロ
7 Operation Check - An illegal buffer address
or incomplete order sequence
7操作Check--不法なバッファアドレスか不完全なオーダー系列
Note 3*: The Intervention Required is cleared by sending an S/S message with the "Device End" bit (Bit 6 of S/S byte 0). The LUSTAT sent to the host is 0X00010000. The IBM host interprets this as a "printer now ready" condition.
注意3*: Intervention Requiredは、「デバイスエンド」ビット(S/Sバイト0のビット6)でS/Sメッセージを送ることによって、きれいにされます。 ホストに送られたLUSTATは0×00010000です。 IBMのホストは「現在が準備するプリンタ」状態としてこれを解釈します。
Note 4*: The Component disconnected is cleared by sending an S/S message with the "Device End" bit (Bit 6 of S/S byte 0). The LUSTAT sent to the host is 0X082B0000. The IBM host interprets this as a "printer now ready -- presentation space integrity may be lost" condition.
注意4*: 切断されたComponentは、「デバイスエンド」ビット(S/Sバイト0のビット6)でS/Sメッセージを送ることによって、きれいにされます。 ホストに送られたLUSTATは0X082B0000です。 IBMのホストは「現在が準備するプリンタ--プレゼンテーションスペース保全は失われるかもしれない」という状態としてこれを解釈します。
Graves, Butts & Angel [Page 9] RFC 1646 TN3270 Extensions July 1994
墓、尻、および天使[9ページ]RFC1646TN3270拡大1994年7月
6. The following is an example of the Client-Server negotiation
process.
6. ↓これはClient-サーバ交渉プロセスに関する例です。
Server: IAC DO TERMINAL-TYPE
Client: IAC WILL TERMINAL-TYPE
Server: IAC SB TERMINAL-TYPE SEND IAC SE
Client: IAC SB TERMINAL-TYPE IS IBM-3287-1 IAC SE
サーバ: IACは端末のタイプクライアントをします: IACウィル端末のタイプサーバ: IAC SBの端末のタイプはIAC SEクライアントを送ります: IAC SBの端末のタイプはIBM-3287-1IAC SEです。
Note: To request a specific LU the TERMINAL-TYPE string would be:
IAC SB TERMINAL-TYPE IS IBM-3287-1 @ LUNAME IAC SE
(The client has specified its terminal type is an IBM-3287-1)
以下に注意してください。 特定のLUを要求するために、TERMINAL-TYPEストリングは以下の通りでしょう。 IAC SBの端末のタイプはIBM-3287-1@LUNAME IAC SEです。(クライアントが持っている、指定されて、端末のタイプがIBM-3287-1である、)
Server: IAC DO END-OF-RECORD
Client: IAC WILL END-OF-RECORD
Server: IAC WILL END-OF-RECORD
Client: IAC DO END-OF-RECORD
サーバ: IACは記録の終わりのクライアントをします: IACウィル記録のエンドServer: IACウィル記録の終わりのClient: IACは記録を終わらせます。
(The Server and Client have both agreed to transmit End-Of-Record
(EOR)).
(ServerとClientは、記録のEnd(EOR)を伝えるのにともに同意しました。)
Server: IAC DO TRANSMIT-BINARY
Client: IAC WILL TRANSMIT-BINARY
Server: IAC WILL TRANSMIT-BINARY
Client: IAC DO TRANSMIT-BINARY
(The Server and Client have both agreed to use binary
transmission)
サーバ: IACはバイナリーを伝えているクライアントをします: バイナリーを伝えているIACウィルServer: バイナリーを伝えているIACウィルClient: IACはバイナリーを伝えてします。(ServerとClientは、2進のトランスミッションを使用するのにともに同意しました)
Server: 0x00 (3270 PRINT DATA)
Client: (S/S with DEV END) IAC EOR
Server: 0x00 (3270 PRINT DATA) IAC EOR
サーバ: 0×00(3270はデータを印刷する)クライアント: (DEVエンドがあるS/S) IAC EORサーバ: 0×00(3270はデータを印刷する)IAC EOR
NOTE: LU 1 type data is prefaced with a 0x00 character. LU 3
type data is not prefaced with a special character. This
character will precede print data in each chain, and should be
discarded before the print data is processed. An <IAC EOR> must
be received before changing to LU 1 or LU 3 type data.
以下に注意してください。 LU1タイプデータは0×00キャラクタと共に前書きされます。 LU3タイプデータは特殊文字で前書きされません。 このキャラクタは、各チェーンで印刷データに先行して、印刷データが処理される前に捨てられるべきです。 LU1に変化するか、LU3がデータをタイプする前に<IAC EOR>を受け取らなければなりません。
Client: (S/S with IR) IAC EOR (This indicates a paper jam
at printer.)
Client: (S/S with DE) IAC EOR (This indicates the clearing
of above condition.)
Server: 0x00 (3270 PRINT DATA) (This indicates start of LU 1
data)
クライアント: (IRがあるS/S) IAC EOR(これはプリンタで紙のジャムを示します。) クライアント: (DEがあるS/S) IAC EOR(これは上記の状態の開拓地を示します。) サーバ: 0×00 (3270の印刷データ)(これはLU1データの始まりを示します)
Server: (3270 PRINT DATA)
サーバ: (3270の印刷データ)
Graves, Butts & Angel [Page 10] RFC 1646 TN3270 Extensions July 1994
墓、尻、および天使[10ページ]RFC1646TN3270拡大1994年7月
Server: (3270 PRINT DATA)
Server: (3270 PRINT DATA) IAC EOR
Client: (S/S with DE) IAC EOR
Server: 0x00 (LAST 3270 PRINT DATA) IAC EOR
サーバ: (3270の印刷データ) サーバ: (3270の印刷データ) IAC EORクライアント: (DEがあるS/S) IAC EORサーバ: 0×00(3270の印刷データを持続する)IAC EOR
Client: (S/S with DE) IAC EOR
Server: IAC AO
(The Abort Output <AO> signifies the end-of-bracket -- end of
print job)
クライアント: (DEがあるS/S) IAC EORサーバ: IAC AO(Abort Output<AO>はブラケットの端を意味します--印刷仕事の終わり)
7. SECURITY CONSIDERATIONS
7. セキュリティ問題
This document does not specify a security methodology to insure that the client requesting a printer LU name is authorized to access that LU. Currently, this is left up to individual server implementations. The design of the protocols described in this document allow for the future incorporation of the RFCs regarding encryptions and authentication protocols and services. However, before this may occur, certain extensions may be required to the protocols defined in this document or to the encryptions and authentication services and protocols.
このドキュメントは、プリンタLU名を要求するクライアントがそのLUにアクセスするのに権限を与えられるのを保障するためにセキュリティ方法論を指定しません。 現在、これは個々のサーバ実装に任せられます。 本書では説明されたプロトコルのデザインは暗号化、認証プロトコル、およびサービスに関してRFCsの今後の編入を考慮します。 しかしながら、これが起こるかもしれない前に、ある拡大が本書では定義されたプロトコル、または、暗号化と、認証サービスとプロトコルに必要であるかもしれません。
8. ERROR CONDITIONS
8. エラー条件
After a client and server have successfully completed negotiation, a number of potential error conditions may be detected by the server which require notifying the client and aborting the connection.
クライアントとサーバが首尾よく交渉を終了した後に、多くの潜在的エラー条件がサーバによって検出されるかもしれません(クライアントに通知して、接続を中止するのを必要とします)。
When an error condition is detected by the server, the client must be negotiated back into NVT mode by the server sending a "WONT/DONT BINARY" TELNET sequence and the client responding with the appropriate "DONT/WONT BINARY" TELNET sequence.
エラー条件がサーバによって検出されるとき、「習慣/ドントBINARY」telnet系列とクライアントが適切な「ドント/習慣バイナリー」telnet系列で応じるサーバでNVTモードとクライアントを交渉して戻さなければなりません。
The server should immediately send the appropriate error message to the client as an ASCII string and then close the connection. The error message should be prefixed by a numeric identifier to precisely notify the client of the specific error condition. The error message sent to the client should be routed to the proper console or log for corrective action.
サーバは、すぐに、ASCIIストリングとして適切なエラーメッセージをクライアントに送って、次に、接続を終えるべきです。 エラーメッセージは数値識別子によって前に置かれていて、特定のエラー条件について正確にクライアントに通知するべきです。 クライアントに送られたエラーメッセージは修正措置のための適切なコンソールかログに発送されるべきです。
Below is a list of error conditions identified by numeric value, error text, meaning of the error and recovery procedure.
以下に、数値、誤りテキスト、誤りとリカバリ手順の意味によって特定されたエラー条件のリストがあります。
Message: "01 No LU's of the type configured"
メッセージ: 「01 タイプのLUは全く構成されていません」
Meaning: The configuration definition on the server
does not include the LU type requested.
意味: サーバにおける構成定義はタイプが要求したLUを含んでいません。
Graves, Butts & Angel [Page 11] RFC 1646 TN3270 Extensions July 1994
墓、尻、および天使[11ページ]RFC1646TN3270拡大1994年7月
Recovery: Notify your Systems Administrator as this
is a permanent error condition.
回復: これが永続エラー状態であるので、初級システムアドミニストレータに通知してください。
Message: "02 Requested LU unavailable"
メッセージ: 「入手できない02要求されたLU」
Meaning: The requested LU is not available at
this time.
意味: 要求されたLUはこのとき、利用可能ではありません。
Recovery: This may be a temporary error and may
be retried periodically. If the condition
persists contact your Systems Administrator.
回復: これは、一時的な誤りであるかもしれなく、定期的に再試行されるかもしれません。 状態が持続するなら、初級システムアドミニストレータに連絡してください。
Message: "03 Requested LU type is inconsistent with configuration"
メッセージ: 「03 要求されたLUタイプは構成に反しています」
Meaning: The LU requested does not match the terminal
type in the server configuration.
意味: 要求されたLUはサーバ構成で端末のタイプに合っていません。
Recovery: Notify your Systems Administrator as this
is a permanent error condition.
回復: これが永続エラー状態であるので、初級システムアドミニストレータに通知してください。
Message: "04 Requested LU is not configured"
メッセージ: 「04 要求されたLUは構成されません」
Meaning: The LU is not defined in server configuration.
意味: LUはサーバ構成で定義されません。
Recovery: Notify your Systems Administrator as this
is a permanent error condition.
回復: これが永続エラー状態であるので、初級システムアドミニストレータに通知してください。
When a client receives a message not defined in the above list, the message should be displayed to a console or log and the connection to the server should be closed. No other recovery should be attempted as this is most likely a fatal error condition. (Notify your Systems Administrator.)
クライアントが上記のリストで定義されなかったメッセージを受け取るとき、コンソールかログにメッセージを表示するべきです、そして、サーバとの接続を閉店させるべきです。 これがたぶん致命的なエラー条件であるので、他の回復を全く試みるべきではありません。 (初級システムアドミニストレータに通知してください。)
9. REFERENCES
9. 参照
[1] Postel, J., and J. Reynolds, "TELNET Protocol Specification", STD
8, RFC 854, USC/Information Services Institute, May 1983.
[1] ポステル、J.、およびJ.レイノルズ、「telnetプロトコル仕様」、STD8、RFC854(サービスが設けるUSC/情報)は1983がそうするかもしれません。
[2] VanBokkeln, J., "TELNET Terminal-Type Option" RFC 1091, FTP
Software Inc., February 1989.
[2]VanBokkeln、J.、「telnet端末のタイプオプション」RFC1091、FTPソフトウェア株式会社、1989年2月。
[3] Postel, J., and J. Reynolds, "TELNET Binary Transmission", STD
27, RFC 856, USC/Information Services Institute, May 1983.
[3] ポステル、J.、およびJ.レイノルズ、「telnetバイナリー送信」、STD27、RFC856(サービスが設けるUSC/情報)は1983がそうするかもしれません。
Graves, Butts & Angel [Page 12] RFC 1646 TN3270 Extensions July 1994
墓、尻、および天使[12ページ]RFC1646TN3270拡大1994年7月
Authors' Addresses
作者のアドレス
Cleve Graves
2711 LBJ Freeway
Dallas, Texas 75234
クリーブグラーブ2711LBJ Freewayダラス、テキサス 75234
Phone: (214) 484-5200
EMail: cvg@oc.com
以下に電話をしてください。 (214) 484-5200 メールしてください: cvg@oc.com
Thomas Butts
2711 LBJ Freeway
Dallas, Texas 75234
トーマスは2711LBJ Freewayダラス、テキサス 75234を接合します。
Phone: (214) 484-5200
EMail: tom@oc.com
以下に電話をしてください。 (214) 484-5200 メールしてください: tom@oc.com
Michelle Angel
2711 LBJ Freeway
Dallas, Texas 75234
ミシェルAngel2711LBJ Freewayダラス、テキサス 75234
Phone: (214) 484-5200
EMail: angel@oc.com
以下に電話をしてください。 (214) 484-5200 メールしてください: angel@oc.com
Graves, Butts & Angel [Page 13]
墓、尻、および天使[13ページ]
一覧
スポンサーリンク
