RFC88 日本語訳
0088 NETRJS: A third level protocol for Remote Job Entry. R.T. Braden,S.M. Wolfe. January 1971. (Format: TXT=19691 bytes) (Obsoleted by RFC0189) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group R. Braden Request for Comments: 88 S. Wolfe NIC: 5668 UCLA/CCN 13 January 1971
コメントを求めるワーキンググループR.ブレーデン要求をネットワークでつないでください: 88秒間ウルフNIC: 5668 UCLA/CCN1971年1月13日
NETRJS - A THIRD LEVEL PROTOCOL FOR REMOTE JOB ENTRY
NETRJS--リモートジョブエントリのための第3の平らなプロトコル
A. Introduction
A.序論
NETRJS is the name for a message protocol and set of control conventions which will allow users at remote Hosts to access the RJS ("Remote Job Service") remote batch subsystem of CCN. RJS[1] was written at CCN to support remote batch (car reader/line printer) terminals over communications lines.
NETRJSはリモートHostsのユーザをCCNのRJS(「リモート・ジョブサービス」)リモートバッチサブシステムにアクセスさせるコントロールコンベンションのメッセージプロトコルとセットのための名前です。 RJS[1]は、コミュニケーション系列の上でリモートバッチ(車の読者/ラインプリンタ)端末を支えるためにCCNに書かれました。
RJS makes a remote batch terminal's unit record devices operate as if they were at the central site; thus, a remote user enters OS/360 jobs, complete with JCL, into the remote reader. The jobs are spooled into the operating system and run in their turn, and the printed and/or punched output is returned to the remote terminal from which the jobs originated (unless the user or operator re-routes the output). The remote terminal may also include a console typewriter to be used by the remote operator to receive and send messages and to exert control over his terminal [2].
まるでそれらが主要なサイトにあるかのようにRJSはリモートバッチ端末のユニットレコード装置を作動させます。 したがって、リモート・ユーザーは完全なJCLと共にOS/360の仕事をリモート読者に入れます。 仕事は、オペレーティングシステムにスプールされて、彼らの回転に立候補します、そして、印刷されたそして/または、パンチされた出力は仕事が起因した遠隔端末に返されます(ユーザかオペレータが出力を別ルートで送らない場合)。 また、メッセージを受け取って、送って、彼の端末[2]のコントロールを及ぼすのにリモートオペレータによって使用されるように、遠隔端末はコンソールタイプライタを含むかもしれません。
When RJS is used via the ARPA Network, the "remote terminal" is expected to be a multiprogrammed user process in a remote Host. We will use the RJS term "remote site" for such a user process, which presumably simulates unit record devices by file I/O. Furthermore, several users at the same remote Host may simultaneously use NETRJS, acting as independent "remote sites" distinguished by 8-character names called _terminal-ids_ (because each remote site appears to RJS as a separate physical terminal). Valid terminal-ids will be assigned to individual users or user groups at remote Hosts who wish to use NETRJS.
RJSがアーパネットで使用されるとき、「遠隔端末」はリモートHostのマルチプログラムのユーザ・プロセスであると予想されます。 私たちはそのようなユーザ・プロセスに「リモートサイト」というRJS用語を使用するつもりです。(おそらく、それは、ファイル入出力でユニットレコード装置をシミュレートします)。 その上、同じリモートHostの数人のユーザが同時にNETRJSを使用するかもしれません、独立している「リモートサイト」が_端末の免疫不全症候群_と呼ばれる8キャラクタの名前によって区別されながら(各リモートサイトが別々の物理端末としてRJSにおいて現れるので)行動して。 有効な端末のイドはNETRJSを使用したがっているリモートHostsで個々のユーザかユーザ・グループに配属されるでしょう。
Under NETRJS, a separate ARPA network connection is opened from this remote site to CCN for each (simulated) unit record device. Each such connection will be called a _channel_ and be designated _input_ or _output_ with reference to CCN. We define a _standard_ remote site in NETRJS to have the following five channels (See Figure 1):
NETRJSの下では、別々のARPAネットワーク接続はそれぞれの(シミュレートされます)ユニットレコード装置のためにこのリモートサイトからCCNまで開かれます。 そのような各接続は、_チャンネル_と呼ばれて、CCNに関して_入力_か_出力_に任命されるでしょう。 私たちは以下の5個のチャンネルがあるようにNETRJSの_の標準の_リモートサイトを定義します(図1を見てください):
1._Operator Input Channel_ - Commands and messages entered by remote "operator" console.
1._オペレータInput Channel_ ―コマンドとメッセージはリモート「オペレータ」コンソールから入りました。
2 _Operator Output Channel_ - Message stream which would normally be directed to remote operator.
通常、リモートオペレータに向けられる2_オペレータOutput Channel_ ―メッセージストリーム。
Braden, et. al. [Page 1] RFC 88 NETRJS - A THIRD LEVEL PROTOCOL 13 January 1971
etブレーデン、アル。 [1ページ]RFC88NETRJS--3分の1にプロトコル1971年1月13日を平らにしてください。
3._Input Stream_ - One simulated Hollerith card reader for job submission.
3. _入力Stream_ ―1はジョブ依頼のために穿孔カード読者をシミュレートしました。
4._Printer Stream_ - One simulated line printer to record printed output (system messages and SYSOUT data sets) from jobs.
4. _プリンタStream_ ―1は、仕事からプリント出力(システムメッセージとSYSOUTデータセット)を記録するためにラインプリンタをシミュレートしました。
5._Punch Stream_ - One simulated card punch, capable of recording arbitrary (i.e., transparent) binary text.
5. _パンチStream_ ―1は任意(すなわち、透明な)の2進のテキストを記録できるカードパンチをシミュレートしました。
RJS actually will support more than one reader, printer, and punch at each remote terminal, so the NETRJS protocol could easily be expanded to allow multiple simultaneous I/O streams to each Network user. However, this does not presently appear useful, as the ARPA Network bandwidth will normally be the limitation on the transmission speed under NETRJS.
RJSが実際に各遠隔端末での1つ以上の読者、プリンタ、およびパンチを支えるので、複数の同時の入出力ストリームをそれぞれのNetworkユーザに許容するために容易にNETRJSプロトコルを広げることができました。 しかしながら、これは現在役に立つように見えません、アーパネット帯域幅が通常NETRJSの下の伝送速度における制限であるので。
Under NETRJS, the text of a single network message is called a _block_. A block is of variable length, up to 900 bytes (except operator input and output blocks, which may not exceed 130 bytes). Here the term _byte_ refers to the set of 8 bits representing one character; each byte is to be aligned on an 8-bit boundary within the message (and block). Thus we may consider a block to be a string of bytes. The detailed format of a block will be defined in Sections E, F, and G, using essentially the formalism suggested by Bobrow and Sutherland in RFC #31.
NETRJSの下では、ただ一つのネットワークメッセージのテキストは_ブロック_と呼ばれます。ブロックは可変長のものです、最大900バイト(130バイトを超えないかもしれないオペレータ入出力ブロックを除いて)。 ここと、用語_バイト_は1つのキャラクタの代理をする8ビットのセットを呼びます。 各バイトはメッセージ(そして、ブロック)の中の8ビットの境界で並べられることです。 したがって、私たちは、ブロックが一連のバイトであると考えるかもしれません。 1ブロックの詳細な書式はセクションE、F、およびGで定義されるでしょう、本質的にはRFC#31でBobrowとサザーランドによって提案された形式を使用して。
Since the central site Host (CCN) is an IBM 360, NETRJS uses the IBM EBCDIC character code to avoid redundant code conversion at both hosts in those cases when the remote host also uses EBCDIC internally. However, the message formats make no assumption about the code, and in fact, "object decks" sent to the (simulated) card punch will normally contain arbitrary binary text.
主要なサイトHost(CCN)がIBM360であるので、また、リモートホストが内部的にEBCDICを使用すると、NETRJSは両方のホストでそれらの場合で冗長符号変換を避けるのにIBM EBCDlC文字コードを使用します。 しかしながら、メッセージ・フォーマットはコードに関する仮定を全くしません、そして、事実上、通常、(シミュレートされます)カードパンチに送られた「オブジェクト・デック」は任意の2進のテキストを含むでしょう。
To maximize the use of the available Network bandwidth, we strongly recommend transmitting input blocks as large as possible; CCN will always fully block NETRJS output. Furthermore, to avoid excessive overhead, we urge that all NETRJS users make their marking _a multiple of 8 bits_, so the messages received at CCN arrive on a byte boundary.
利用可能なNetwork帯域幅の使用を最大にするために、私たちは、入力ブロックを伝えることを強くできるだけ大きい状態で勧めます。 CCNはNETRJS出力を完全にいつも妨げるでしょう。 その上、過度のオーバーヘッドを避けるために、私たちが、すべてのNETRJSユーザが彼らに8ビットの_について_a倍数をマークさせるよう促すので、CCNに受け取られたメッセージはバイト境界で到着します。
B. Starting a Session[3]
B. セッションを始めること。[3]
The initial connection protocol for NETRJS is essentially that of Crocker in RFC #66 (as restated by Harslem and Heafner in RFC #80), with some extensions. User U at a remote Host presumably requests his outgoing logger to make a NETRJS connection to CCN. This
NETRJSのための初期の接続プロトコルは本質的にはRFC#66におけるクロッカーのもの(RFC#80でHarslemとHeafnerによって言い直されるように)です、いくつかの拡大で。 おそらく、リモートHostのユーザUは、NETRJS接続をCCNに作るよう彼の外向的なきこりに要求します。 これ
Braden, et. al. [Page 2] RFC 88 NETRJS - A THIRD LEVEL PROTOCOL 13 January 1971
etブレーデン、アル。 [2ページ]RFC88NETRJS--3分の1にプロトコル1971年1月13日を平らにしてください。
logger does so by first sending an initial RFC to connect socket (user,aen) = (U,s) to CCN socket (0,5). User 0 at CCN is the incoming logger, and aen = 5 signifies NETRJS.
きこりは、最初にソケット(ユーザ、aen)=(U、s)をCCNソケット(0、5)に接続するために初期のRFCを送ることによって、そうします。 CCNのユーザ0は入って来るきこりです、そして、aen=5はNETRJSを意味します。
The CCN incoming logger will allocate a set of (six) consecutive aen numbers A, A+1,......A+5, for user U, return a message containing the socket number (U,A) as specified in RFC #66, and close the initial connection. The remote and central sites will then open an input channel between CCN socket (U,A) (socket f in Figure 1) and remote socket (U, s+1). This is the remote operator input channel. The other devices have fixed aen's at CCN assigned relative to A, in particular:
CCN入って来るきこりは(6)連続したaen番号A、1セットのA+1を割り当てるでしょう…+5をユーザUのためにRFC#66における指定されるとしてのソケット番号(U、A)を含むメッセージを返して、初期の接続を終えます。 そして、リモートで主要なサイトはCCNソケット(U、A)(図1のソケットf)とリモートソケット(U、s+1)の間の入力チャンネルを開けるでしょう。 これはリモートオペレータ入力チャンネルです。 対向機器はAに比例して特に割り当てられたCCNにaenを固定しました:
CCN Socket Channel (User,aen)
CCNソケットチャンネル(ユーザ、aen)
Operator Input (U,A) Operator Output (U,A+1) Card Reader (No. 1) (U,A+2) Printer (No. 1) (U,A+3) Punch (No. 1) (U,A+5)
オペレータ入力、(U、a)オペレータ出力(U、+1)カードリーダ(No.1)(U、+2)プリンタ(No.1)(U、+3)パンチ(No.1)(U、+5)
Once the operator input channel is open, the remote site must transmit a valid RJS signon message [2]. This message is free-format and consists of the command verb "SIGNON" followed by the user's terminal-id. If RJS does not recognize the terminal-id or has no available Line Handler for the Network, it will indicate refusal by closing the operator input channel. Central site issues subsequent RFC's for the other channels listed above only in response to corresponding RFC's from the remote site
オペレータ入力チャンネルがいったんオープンになると、リモートサイトは有効なRJS signonメッセージ[2]を送らなければなりません。 このメッセージは、フリー・フォーマットであり、ユーザの端末のイドがあとに続いたコマンド動詞の"SIGNON"から成ります。 RJSに、端末のイドを認識しないか、またはNetworkのためのどんな利用可能な線Handlerもないと、それは、オペレータ入力チャンネルを閉じることによって、拒否を示すでしょう。 他のチャンネルのためのその後のRFCが上に単にリモートサイトからの対応するRFCのものに対応して記載した主要なサイト問題
To terminate the session, the remote site may close the console input channel (socket "a" in figure 1). Alternatively, the user can enter a SIGNOFF command through the operator input channel; in this case, RJS will wait until the current job output streams are complete and then terminate the session. RJS terminates the session by closing the console output channel (socket g). Also, if RJS should abend then socket g will close. If either site terminates the session, all other connections for this remote site should be closed. Note that a user can submit a number of jobs, sign off, and later receive his output when he signs on again.
セッションを終えるために、リモートサイトはコンソール入力チャンネル(1図のソケット“a")を閉じるかもしれません。 あるいはまた、ユーザはオペレータ入力チャンネルによるSIGNOFFコマンドを入力できます。 この場合、現在のジョブ出力ストリームが終了していて、次に、セッションを終えるまで、RJSは待つでしょう。 RJSは、コンソール出力チャネル(ソケットg)を閉じることによって、セッションを終えます。 また、RJSがアベンドすると、ソケットgは閉じるでしょう。 どちらのサイトもセッションを終えるなら、このリモートサイトのための他のすべての接続が閉店するべきです。 ユーザが多くの仕事を提出できることに注意してください、そして、サインオフしてください、そして、彼が再び雇われたら後で彼の出力を受けてください。
C. Channel Control
C。 流通経路統制
Flow control in NETRJS is handled by the Network protocol ALL mechanism. Before transmission of a stream of records can begin on a particular channel, the remote site must issue an RFC and Central must reply. This allows the central site to determine the remote
NETRJSのフロー制御は扱われて、Networkがすべてのメカニズムについて議定書の中で述べるということです。 記録のストリームのトランスミッションが特定のチャンネルの上に始まることができる前に、リモートサイトはRFCを発行しなければなりません、そして、セントラルは返答しなければなりません。 これで、主要なサイトはリモートを決定できます。
Braden, et. al. [Page 3] RFC 88 NETRJS - A THIRD LEVEL PROTOCOL 13 January 1971
etブレーデン、アル。 [3ページ]RFC88NETRJS--3分の1にプロトコル1971年1月13日を平らにしてください。
configuration dynamically. A particular card reader, printer, or punch channel is open only while it is active, so the receiver need not tie up buffer space needlessly. Each of these channels, when open, assumes a buffer allocation of at least 900 bytes at the receiver.
構成、ダイナミックに。 それが単にアクティブですが、特定のカードリーダ、プリンタ、またはパンチチャンネルがオープンであるので、受信機は不必要にバッファ領域をタイアップする必要はありません。 開くとき、これらのチャンネル各人は、受信機でバッファが少なくとも900バイトの配分であると仮定します。
The operator input and output channels, on the other hand, are open throughout the session. On these channels the receiver must provide an allocation of at least 130 bytes.
他方では、オペレータ入力と出力チャネルはセッションの間中開いています。 これらのチャンネルで、受信機は少なくとも130バイトの配分を提供しなければなりません。
After sending the SIGNON command over the operator input channel, the remote site should send RFC's for all output channels which are ready to receive data. When output is available for that site, Central returns an RFC and begins transmission. Central closes an output channel (socket i and j) at the end of the output for each complete batch job.[4] The remote site must then send a new RFC and Central must reply with an RFC to start output for another job to that device. This gives the remote site a chance to allocate a new file for each job without breaking the output within a job. If the user at the remote site wants to cancel (or backspace or defer) the output of a particular job, he enters appropriate RJS commands[2] on the operator input channel.
オペレータ入力チャンネルの上にSIGNONコマンドを送った後に、リモートサイトはすべてのデータを受け取る準備ができている出力チャネルのためにRFCのものを送るべきです。 出力がそのサイトに利用可能であるときに、セントラルは、RFCを返して、トランスミッションを始めます。 それぞれのための出力の端の出力チャネル(ソケットiとj)が次にリモートサイトが新しいRFCを送らなければならない.[4]とセントラルがRFCと共に返答しなければならないバッチ・ジョブを終了する中央の閉鎖はそのデバイスに別口の仕事のための出力を始動します。 これは仕事の中で出力を壊さないで各仕事のための新しいファイルを割り当てる機会をリモートサイトに与えます。 リモートサイトのユーザが取り消したがっている、(バックスペースキーを押して印字位置を一字分戻ってください、延期、)、特定の仕事の出力、彼はオペレータ入力チャンネルで適切なRJSコマンド[2]を入力します。
When the remote site is ready to submit a job (or stack of consecutive jobs), it issues an RFC for the card reader input channel. The remote site is not required to close the channel (socket c) after each job in a "stack" of jobs, but he must close it following the last job in the stack to initiate its processing.
リモートサイトが仕事(または、連続した仕事のスタック)を提出する準備ができているとき、それはカードリーダ入力チャンネルのためにRFCを発行します。 リモートサイトは仕事の「スタック」での各仕事の後にチャンネル(ソケットc)を閉じるのに必要ではありませんが、処理を開始するスタックにおける最後の仕事に続いて、彼はそれを閉じなければなりません。
It may be necessary for the receiver site to abort a particular channel, perhaps due to a transmission error (see Section D below on checking) or a disk I/O error. The receiver may abort a channel (other than console output) by closing it (sockets d, e, f, and h). This action signals the transmitter to re-transmit the information after the channel has been reopened (initiated by the remote site, as always). The transmitter, on the other hand, aborts a channel by sending a block with a particular bit combination (e = 2 in BCBYTE; see Section E).
受信機サイトが特定のチャンネルを堕胎するのが必要であるかもしれません、恐らく伝送エラー(以下のセクションDを照合に見る)かディスク入出力誤りのため。 受信機は、それ(ソケットd、e、f、およびh)を閉じることによって、チャンネル(コンソール出力を除いた)を堕胎するかもしれません。 この動作は、チャンネルが再開した(リモートサイトで、いつものように開始されます)後に情報を再送するように送信機に示します。 他方では、送信機は、特定のビット・コンビネーションがあるブロックを送ることによって、チャンネルを堕胎します(BCBYTEのe=2; セクションEを見てください)。
If either site aborts card reader (input) channel, RJS will discard the text of the last partially-spooled job; the remote site should re-transmit this job. Note that repeating an entire stack will enter duplicate jobs into the system, but the second copy of a job will "flush" due to its duplicate job name.
どちらのサイトもカードリーダ(入力)チャンネルを堕胎すると、RJSは最後の部分的にスプールさせられた仕事のテキストを捨てるでしょう。 リモートサイトはこの仕事を再送するべきです。 全体のスタックを繰り返すと写し仕事がシステムに入れられますが、仕事の2番目のコピーが写しジョブ名のために「洗い流される」と述べてください。
If a printer or punch (output) channel is aborted, Central will re- transmit from the beginning of the current SYSOUT data set; the effect is the same as a RESTART command.[2]
プリンタかパンチ(出力)チャンネルが堕胎されると、セントラルは現在のSYSOUTデータセットの始まりから再伝わるでしょう。 効果はRESTARTコマンドと同じです。[2]
Braden, et. al. [Page 4] RFC 88 NETRJS - A THIRD LEVEL PROTOCOL 13 January 1971
etブレーデン、アル。 [4ページ]RFC88NETRJS--3分の1にプロトコル1971年1月13日を平らにしてください。
If the operator input channel is aborted, the remote site must re- transmit the last _block_. Finally, the operator output channel has no abort condition defined. Central will never send Channel Abort message on this channel; if the remote site closes its socket (socket b), Central will not re-transmit, but simply cease sending messages until the channel is reopened. Therefore a remote site can operate without an operator output channel; however we do not recommend this, as the user will then miss operator advisory messages such as a warning of an impending IPL.
オペレータ入力チャンネルが堕胎されるなら、リモートサイトは最後の_ブロック_を再伝えなければなりません。最終的に、オペレータ出力チャネルには、定義されなかったアボート状態が全くあります。 セントラルはこのチャンネルでChannel Abortメッセージを決して送らないでしょう。 リモートサイトがソケット(ソケットb)を閉じると、セントラルは再送されないでしょうが、チャンネルが再開するまでメッセージを送るのを単にやめてください。 したがって、リモートサイトはオペレータ出力チャネルなしで作動できます。 しかしながら、私たちはこれを推薦しません、次に、ユーザが差し迫っているIPLに関する警告などのオペレータの顧問メッセージを逃すとき。
D. Checking
D。 チェックします。
The nature of remote job entry service is such that a low rate of undetected errors is mandatory. The IMP's use CRC's and sequence numbers over the communication lines, so the effective IMP-IMP error rate should be negligible. Although there is no checking provided for the IMP-Host interface, it seems likely that these interfaces will either be reliable or fail catastrophically; it seems unlikely that "drop-outs" or other random failures will occur. Therefore only the following simple checks are provided:
リモートジョブエントリサービスの本質がそのようなものであるので、非検出された誤りの低率は義務的です。 IMPのものが通信回線の上でCRCと一連番号を使用するので、有効なIMP-IMP誤り率は取るにたらないはずです。 IMP-ホスト・インターフェースに提供されたチェックがありませんが、これらのインタフェースは、信頼できるか、または不運に失敗しそうでしょう。 「落第生」か他の偶発故障が起こるのはありそうもなく見えます。 したがって、以下の簡単なチェックだけを提供します:
1. Each block will (at least initially) contain a fixed bit check pattern using both on and off states of each bit path in the 16 bit PDA interface at CCN.
1. 各ブロックはCCNに16ビットのPDAインタフェースに時々両方を使用すると述べられるそれぞれの噛み付いている経路の固定噛み付いているチェック・パターンを含むでしょう(少なくとも初めは)。
It is anticipated that even this crude check on IMP-Host transmission will be useful both during the initial checkout of hardware and software and also later if the interface becomes marginal. However, either site can omit the check pattern if it sets a bit in the Block Control Byte (BCBYTE); see Section F.
インタフェースがマージンになると、IMP-ホストトランスミッションのこの粗雑なチェックもさえともにハードウェアとソフトウェアの初期のチェックアウトの間、役に立ってまた、より遅れると予期されます。 しかしながら、Block Control Byte(BCBYTE)に少しセットするなら、どちらのサイトもチェック・パターンを省略できます。 セクションFを見てください。
2. Each block contains a sequence number. Again this is intended for initial checkout and to signal catastrophic hardware or software problems. If the receiver detects an incorrect check pattern or block sequence number, he aborts the channel by closing the corresponding network connection; the remote site should then issue an RFC to re-establish the network connection. The sequence number of the first block after an RFC is 0. The numbers are never reset while the connection is open.
2. 各ブロックは一連番号を含んでいます。 一方、これは、初期のチェックアウト、壊滅的なハードウェアかソフトウェアの問題に合図するつもりです。受信機が不正確なチェック・パターンかブロック法番号を検出するなら、彼は対応するネットワーク接続を終えることによって、チャンネルを堕胎します。 そして、リモートサイトは、ネットワーク接続を復職させるためにRFCを発行するべきです。 RFCの後の最初のブロックの一連番号は0です。 接続がオープンである間、数は決してリセットされません。
Braden, et. al. [Page 5] RFC 88 NETRJS - A THIRD LEVEL PROTOCOL 13 January 1971
etブレーデン、アル。 [5ページ]RFC88NETRJS--3分の1にプロトコル1971年1月13日を平らにしてください。
E. Block Format
E。 ブロックフォーマット
BLOCK <---- BLOCKHEAD + (RECORD = r) + ENDOFBLOCK
ブロック<。---- + BLOCKHEAD+(RECORD=r)ENDOFBLOCK
Here r > 0 = BLOCKHEAD <-- BCBYTE + [e=0=>CHECK] + DEVBYTE
ここで、r>0はでくのぼう<と等しいです--、+ BCBYTE+[eは0=>チェックと等しい]DEVBYTE
The Blockhead field consists of a Block Control Byte, a 32-bit check field CHECK, and a Device Byte.
Blockhead分野はBlock Control Byte、32ビットのチェック分野CHECK、およびDevice Byteから成ります。
BCBYTE <---- '1'BIT + e:ERRORCONTROL + b:BLKSEQ
BCBYTE<。---- '1'ビット+e: ERRORCONTROL+b: BLKSEQ
Here BLKSEQ contains a 5-bit modulo 32 block sequence number b. ERRORCONTROL is a 2 bit field with the following meanings:
ここに、BLKSEQは5ビットの法32ブロック法番号bを含んでいます。 ERRORCONTROLは以下の意味がある2ビットの分野です:
e=0 : Normal block. Contains a (presumably valid) check field CHECK.
e=0: 標準のブロック。 (おそらく有効)のチェック分野CHECKを含んでいます。
e=1 : Block contains no check field CHECK.
e=1: ブロックはチェック分野CHECKを全く含んでいません。
e=2 : Abort channel, initiated by transmitter. Channels is not closed, transmission restarts on job-related boundary.
e=2: 送信機によって着手されたチャンネルを堕胎してください。 閉店しなかったチャンネル、トランスミッションは仕事の関連の境界で再開します。
DEVBYTE <---- '1'BIT + n:DEVNO + t:DEVTYPE
DEVBYTE<。---- '1'ビット+n: DEVNO+t: DEVTYPE
This byte identifies a particular remote device, i.e., it identifies a stream. DEVTYPE specifies the type of device, as follows:
このバイトは特定の遠隔装置を特定します、すなわち、それがストリームを特定します。 DEVTYPEは以下の通りデバイスのタイプを指定します:
t=1: Output to remote operator console. 2: Input from remote operator console. 3: Input from card reader. 4: Output to printer. 5: Output to card punch. 6,7: Unused.
t=1: リモートオペレータコンソールへの出力。 2: リモートオペレータコンソールから、入力します。 3: カードリーダから、入力します。 4: プリンタへの出力。 5: カードパンチへの出力。 6,7: 未使用。
DEVNO is a 3-bit integer which identifies the particular device type of type t at this remote site.
DEVNOはこのリモートサイトで特定の装置タイプのタイプtを特定する3ビットの整数です。
CHECK <--- '10101111'BYTE + 01010000'BYTE + '11111010'BYTE + '00000101'BYTE ENDOFBLOCK<----'0'BYTE
<をチェックしてください。--- ''00000101''11111010''バイト+01010000'バイト+バイト+バイトの10101111ENDOFBLOCK<'----'0'バイト
Braden, et. al. [Page 6] RFC 88 NETRJS - A THIRD LEVEL PROTOCOL 13 January 1971
etブレーデン、アル。 [6ページ]RFC88NETRJS--3分の1にプロトコル1971年1月13日を平らにしてください。
Record Format
レコード形式
RECORD <------ DATA RECORD | JOBNAMERECORD
<を記録してください。------ データレコード| JOBNAMERECORD
The first record sent on a printer or punch output channel will be a JOBNAMERECORD, identifying the OS/360 jobname of the job which produced the following output.
最初の記録は、プリンタかパンチ出力チャネルがJOBNAMERECORDになるのを転送しました、以下の出力を起こした仕事のOS/360jobnameを特定して。
DATARECORD <--- '10'BIT2 + DEVCNTRL + (STRING=p) + ENDOFRECORD
DATARECORD<。--- 10年の'+ BIT2+DEVCNTRL+(ストリング=p)ENDOFRECORD'
JOBNAMERECORD <-- '11000000'BYTE + '11001000'BYTE + JOBNAME + ENDOFRECORD
JOBNAMERECORD<--'11001000''11000000'バイト+バイト+JOBNAME+ENDOFRECORD
JOBNAME <---- (TEXTBYTE = 8)
JOBNAME<。---- (TEXTBYTE=8)
This is the 8-character OS/360 jobname for the following job.
これは以下の仕事のための8キャラクタのOS/360jobnameです。
DEVCNTRL <----- d:BIT2 + k:BIT4
DEVCNTRL<。----- d: BIT2+k: BIT4
DEVCNTRL specifies carriage control for a printer, so if the device is not a printer then DEVCNTRL should be '000000'. For a printer:
DEVCNTRLがプリンタに改行制御を指定するので、デバイスがプリンタでないなら、DEVCNTRLは'000000'であるべきです。 プリンタのために:
d=0 : Space k lines after printing; 0 < k < 3 = = is allowed
d=0: スペースkは印刷の後に立ち並びます。 0 <k<3==は許容されています。
d=2 : Immediately space k lines.
d=2: すぐに、スペースkは立ち並びます。
d=1, k=1: Skip to top of new page after printing.
d=1、k=1: 印刷の後に新しいページの上部までスキップしてください。
d=3, k=1: Immediately skip to top of new page.
d=3、k=1: 至急、新しいページの上部までスキップしてください。
STRING <--- ('100' + i:DUPCOUNT)| This is a string of i consecutive blanks.
ストリング<。--- ('100'+i: DUPCOUNT)| これは一連のi連続した空白です。
('101' + i:DUPCOUNT + TEXTBYTE)|
('101'+i: DUPCOUNT+TEXTBYTE)|
This is a string of i consecutive duplicates of TEXTBYTE.
これはTEXTBYTEの一連のi連続した写しです。
('11' + j:LENGTH + (TEXTBYTE=j)| This is an uncompressed string of j characters.
'、(11年の'+j: LENGTH+(TEXTBYTE=j)| これはjキャラクタの解凍されたストリングです。
ENDOFRECORD <---- '0'BYTE
ENDOFRECORD<。---- '0'バイト
Braden, et. al. [Page 7] RFC 88 NETRJS - A THIRD LEVEL PROTOCOL 13 January 1971
etブレーデン、アル。 [7ページ]RFC88NETRJS--3分の1にプロトコル1971年1月13日を平らにしてください。
G. Field Definitions
G。 フィールド定義
Name* Meaning Length (bits) _____ _______ _____________
名前*意味の長さ(ビット)_____ _______ _____________
BIT 1-bit field 1
BITの1ビットの分野1
BIT2 2-bit field 2
BIT2 2-ビット分野2
BIT4 4-bit field 4
BIT4 4-ビット分野4
BLKSEQ Block sequence number 5
BLKSEQ Block一連番号5
BYTE 8-bit field aligned on 8-bit 8 boundary
8ビットの8境界で並べられたBYTEの8ビットの分野
CHECK Block check number 32
CHECK BlockはNo.32をチェックします。
DEVNO Device number of a given 3 type
与えられた3タイプのDEVNO Device番号
DEVTYPE Device type 4
DEVTYPE Deviceは4をタイプします。
DUPCOUNT Number of replications of 5 duplicated character in compressed text.
5の模写のDUPCOUNT Numberは圧縮されたテキストにキャラクタをコピーしました。
ERRORCONTROL Block transmission error 2 control.
ERRORCONTROL Block伝送エラー2は制御されます。
LENGTH Length in bytes of the 6 following string of text.
テキストの6の次のストリングのバイトで表現されるLENGTH Length。
TEXTBYTE An 8-bit byte of text 8
テキスト8のTEXTBYTE Anの8ビットのバイト
*Note: All non-terminal fields whose names end in "...BYTE" represent bytes in both length and alignment.
*以下に注意してください。 「名前が終わるすべての非端末分野」…"BYTE"は長さと整列の両方にバイトを表します。
Braden, et. al. [Page 8] RFC 88 NETRJS - A THIRD LEVEL PROTOCOL 13 January 1971
etブレーデン、アル。 [8ページ]RFC88NETRJS--3分の1にプロトコル1971年1月13日を平らにしてください。
H. NOTES AND REFERENCES
H.注意と参照
1. Martin, V.A. and Springer, T.W., "Implementation of A Remote Job Service", Technical Report TR2, Campus Computing Network, UCLA, Los Angeles, (undated).
1. マーチンとV.A.とT.W.、「リモート・ジョブサービスの実装」、技術報告書TR2、キャンパスがネットワークを計算することでのUCLA、よりバネのロサンゼルス(日付のない)。
2. The RJS operator commands and messages are described in detail in Reference 1.
2. RJSオペレータコマンドとメッセージはReference1で詳細に説明されます。
3. We use the phrase "starting a session" rather than "logging on" because RJS has its own log on procedure, which is, we suppose, a fourth-level protocol.
3. RJSには手順に関するそれ自身のログがあるので「ログオンする」よりむしろ「セッションを始め」て、私たちは句を使用して、どれがあるかと思います、第4レベルプロトコル。
4. Note that NETRJS uses closing of connections as end-of-file signals.
4. NETRJSがファイルの終り信号として接続の閉鎖を使用することに注意してください。
REMOTE SITE CENTRAL SITE (CCN) +---------------------+ +--------------------+ | a | | | | Console Input o----------->o f | | b | | | | Console Output o<-----------o g | | c | | | | Card Reader o------------o h | | d | | | | Printer o<-----------o i | | e | | | | Card Punch o<-----------o j | | | | | +---------------------+ +--------------------+
リモートサイトの主要なサイト(CCN)+---------------------+ +--------------------+ | a| | | | コンソールInput o----------->o f| | b| | | | コンソールOutput o<。-----------o g| | c| | | | カード読者o------------o h| | d| | | | プリンタo<。-----------o i| | e| | | | カードパンチo<。-----------o j| | | | | +---------------------+ +--------------------+
FIGURE 1 ARPA Network Connections (Channels) For a Standard Remote Site Under NETRJS
NETRJSの下の標準のリモートサイトへの1つのアルパの図ネットワークコネクションズ(チャンネル)
R.T. Braden/rb. S.M. Wolfe
R.T.ブレーデン/rb。 S.M.ウルフ
[This RFC was put into machine readable form for entry] [into the online RFC archives by Lorrie Shiota, 10/01]
[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][ロリー塩田によるオンラインRFCアーカイブへの10/01]
Braden, et. al. [Page 9]
etブレーデン、アル。 [9ページ]
一覧
スポンサーリンク