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ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

Date.setUTCMilliseconds

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る