RFC189 日本語訳
0189 Interim NETRJS specifications. R.T. Braden. July 1971. (Format: TXT=41383 bytes) (Obsoletes RFC0088) (Obsoleted by RFC0599) (Updated by RFC0283) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group R. T. Braden Request for Comments: 189 UCLA/CCN Obsoletes: RFC 88 (NIC 5668) 15 July 1971 NIC 7133 Category: D
コメントを求めるワーキンググループR.T.ブレーデン要求をネットワークでつないでください: 189 UCLA/CCNは以下を時代遅れにします。 RFC88(NIC5668)1971年7月15日NIC7133カテゴリ: D
INTERIM NETRJS SPECIFICATIONS
当座のNETRJS仕様
The following document describes the operation and protocol of the remote job entry service to CCN's 360 Model 91. The interim protocol described here will be implemented as a production service before the end of July. Two host sites (Rand and UCLA/NMC) have written user processes for the interim NETRJS, based on the attached document. Questions on it should be addressed to CCN's Technical Liaison.
以下のドキュメントはCCNの360Model91に対するリモートジョブエントリサービスの操作とプロトコルについて説明します。 ここで説明された当座のプロトコルは7月の終わりまでに生産サービスとして実装されるでしょう。 2つのホストサイト(底ならし革とUCLA/NMC)が添付書類に基づいて当座のNETRJSのためにユーザ・プロセスを書きました。 それの質問はCCNのTechnical Liaisonに扱われるべきです。
It is anticipated that the interim protocol will be superseded in a few months by a revised NETRJS, but the changes will be minor. The revision will bring the data transfer protocol of NETRJS into complete conformity with the proposed Data Transfer Protocol DTP (see RFC #171). The present differences between the DTP and NETRJS protocols are:
当座のプロトコルが数カ月後に改訂されたNETRJSによって取って代わられると予期されますが、変化は小さい方になるでしょう。 改正は提案されたData TransferプロトコルDTPとの完全な適合性にNETRJSのデータ転送プロトコルを運び込むでしょう(RFC#171を見てください)。 DTPとNETRJSプロトコルの現在の違いは以下の通りです。
(a) The format (but not the contents) of the 72 bit transaction
header of NETRJS must be changed to conform with DTP.
(a) DTPに従うために、NETRJSの72ビットのトランザクションヘッダーの形式(しかし、コンテンツでない)を変えなければなりません。
(b) The End-of-Data marker must be changed from X'FE' to X'B40F'.
'(b) データのEndマーカーはX'FE'からX'B40F'に変わらなければなりません。
(c) The initial "modes available" transaction of DTP must be
added.
(c) DTPの「利用可能なモード」初期のトランザクションを加えなければなりません。
(d) Some of the DTP error codes will be implemented.
(d) DTPエラーコードのいくつかが実装されるでしょう。
No other protocol changes are presently planned, although some may be suggested by operating experience with the interim protocol. When the revised protocol has been fully specified, it will be implemented with different ICP sockets than the interim protocol. This will allow a site which wants to start using CCN immediately to convert his protocol at leisure.
或るものは当座のプロトコルの運転経験で示されるかもしれませんが、他のプロトコル変化は全く現在、計画されていません。 改訂されたプロトコルが完全に指定されたとき、それは当座のプロトコルと異なったICPソケットで実装されるでしょう。 これで、すぐにCCNを使用し始めたがっているサイトはレジャーで彼のプロトコルを変換できるでしょう。
Some possible future extensions to NETRJS which have been suggested are:
示されたNETRJSへのいくつかの可能な今後の拡大は以下の通りです。
(1) A 7-bit ASCII option of data transfer connections, for the
convenience of PDP-10s.
(1) 10PDP-年代の都合のためのデータ転送コネクションの7ビットのASCIIオプション。
Braden [Page 1] RFC 189 Interim NETRJS Specifications July 1971
当座のNETRJS仕様ブレーデン[1ページ]RFC189 1971年7月
(2) A "transparency" mode for input from ASCII remote sites, to
allow the transmission of "binary decks" (object decks) in
the job stream from these sites.
(2) 「透明」モード、ASCIIからリモートサイトを入力して、これらのサイトからのジョブストリームにおける、「2進のデッキ」(オブジェクト・デック)のトランスミッションを許容してください。
(3) More than one simultaneous virtual card read, printer, and
punch stream to the same virtual terminal.
(3) 同時のバーチャルカードが読んだより多くのもの、プリンタ、およびパンチは同じ仮想端末に流れます。
Comments on the utility of these proposals or others for your site would be appreciated.
これらの提案に関するユーティリティのコメントかあなたのサイトへの他のものをよろしくお願いします。
Robert T. Braden
Technical Liaison
UCLA/CCN
(213) 825-7518
ロバート・T.ブレーデンTechnicalの連絡UCLA/CCN(213)825-7518
Braden [Page 2] RFC 189 Interim NETRJS Specifications July 1971
当座のNETRJS仕様ブレーデン[2ページ]RFC189 1971年7月
REMOTE JOB ENTRY TO UCLA/CCN
FROM THE ARPA NETWORK
アルパネットワークからのUCLA/CCNへのリモートジョブエントリ
(Interim Protocol)
(当座のプロトコル)
A. Introduction
A。 序論
NETRJS is the protocol for the remote job entry service to the 360
Model 91 at the UCLA Campus Computing Network (CCN). NETRJS allows
the user at a remote host to access CCN's RJS ("Remote Job Service")
sub-system, which provides remote job entry service to real remote
batch (card reader/line printer) terminals over direct communications
lines as well as to the ARPA Network.
NETRJSはUCLA Campus Computing Network(CCN)の360Model91に対するリモートジョブエントリサービスのためのプロトコルです。 NETRJSはリモートホストのユーザをCCNのRJS(「リモート・ジョブサービス」)サブシステムにアクセスさせます。(それは、アーパネットに関して本当のリモートバッチ(カードリーダ/ラインプリンタ)端末に対するリモートジョブエントリサービスをまた、ダイレクトコミュニケーション系列の上に提供します)。
To use NETRJS, a user at a remote host needs a NETRJS user process to communicate with one of the NETRJS server processes at CCN. Each active NETRJS user process appears to RJS as a separate (virtual) remote batch terminal; we will refer to it as a VRBT.
NETRJSを使用するなら、リモートホストのユーザは、CCNのNETRJSサーバプロセスの1つとコミュニケートするためにNETRJSユーザ・プロセスを必要とします。 それぞれのアクティブなNETRJSユーザ・プロセスは別々(仮想の)のリモートバッチ端末としてRJSにおいて現れます。 私たちはそれをVRBTと呼ぶつもりです。
A VRBT may have virtual card readers, printers, and punches. Through a virtual card reader a Network user can transmit a stream of card images comprising one or more OS/360 jobs, complete with Job Control Language, to CCN. These jobs will be spooled into CCN's batch system (OS/360 MVT) and run according to their priority. RJS will automati- cally return the print and/or punch output images which are created by these jobs to the virtual printer and/or card punch at the VRBT from which the job came (or to a different destination specified in the JCL). The remote user can wait for his output, or he can sign off and sign back on later to receive it.
VRBTには、仮想のカードリーダ、プリンタ、およびパンチがあるかもしれません。 バーチャルカード読者を通して、Networkユーザは1つを含むカードイメージか、より多くのOS/360の仕事のストリームを伝えることができます、Job Control Languageと共に完全です、CCNに。 これらの仕事は、CCNのバッチシステム(OS/360MVT)にスプールされて、それらの優先権に従って、実行されるでしょう。 RJSは警察署が仮想のプリンタ、そして/または、カードパンチへのこれらの仕事で仕事が来た(またはJCLで指定された異なった目的地に)VRBTに作成される印刷、そして/または、パンチ出力イメージを返すautomatiがそうするでしょう。 リモート・ユーザーが彼の出力を待つことができるか、彼は、サインオフして、後でそれを受けるのを署名の上雇い返すことができます。
The VRBT is assumed to be under the control of the user's teletype or other remote console; this serves the function of an RJS remote operator console. To initiate a NETRJS session, the remote user must execute the standard ICP (see RFC #165) to a fixed socket at CCN. The result is to establish a duplex Telnet connection to his console, allowing the user to sign into RJS. Once he is signed in, he can use his console to issue commands to RJS and to receive status, confirma- tion, and error messages from RJS. The most important RJS commands are summarized in Appendix D.
VRBTがユーザのテレタイプか他のリモートコンソールのコントロールの下にいると思われます。 これはRJSのリモートオペレータコンソールの機能を果たします。 NETRJSセッションを開始するために、リモート・ユーザーは標準のICP(RFC#165を見る)をCCNの固定ソケットに実行しなければなりません。 結果はユーザがRJSに署名するのを許容して、重複のTelnet接続を彼のコンソールに確立することです。 いったんサインインされると、彼は、RJSに命令を出して、RJSから状態、confirma- tion、およびエラーメッセージを受け取るのにコンソールを使用できます。 最も重要なRJSコマンドはAppendix Dにまとめられます。
Different VRBT's are distinguished by 8-character terminal id's. There may be more than one VRBT using RJS simultaneously from the same remote host. Terminal id's for new VRBT's will be assigned by CCN to individual users or user groups who wish to run batch jobs at CCN (contact the CCN Technical Liaison for details).
異なったVRBTのものはイドの8文字端末のものによって区別されます。 同時に同じリモートホストからRJSを使用する1VRBTがあるかもしれません。 新しいVRBTのもののための端末のイドのものはCCNによって個々のユーザかバッチ・ジョブをCCNに実行したがっているユーザ・グループに配属されるでしょう(詳細のためにCCN Technical Liaisonに連絡してください)。
Braden [Page 3] RFC 189 Interim NETRJS Specifications July 1971
当座のNETRJS仕様ブレーデン[3ページ]RFC189 1971年7月
B. Connections and Protocols
B。 コネクションズとプロトコル
Figure 1 shows conceptually the processes and protocols required to use NETRJS. The operator console uses a duplex connection under the Telnet third-level protocol (see RFC #158). The actual data transfer streams for job input and output are handled over separate simplex connections using a data transfer protocol.
図1は、プロセスとプロトコルがNETRJSを使用するのが必要であることを概念的に示します。 オペレータコンソールはTelnet第3レベルプロトコルの下に重複の接続を使用します(RFC#158を見てください)。 仕事の入出力のための実際のデータ転送ストリームは、別々のシンプレクス接続の上でデータ転送プロトコルを使用することで扱われます。
We will use the term channel for one of these NETRJS connections, and designate it input or output with reference to CCN. Each data transfer channel is identified with a particular virtual remote dev- ice -- card reader, printer, or punch. The data transfer channels need be open only while they are in use, and different channels may be used sequentially or simultaneously. NETRJS will presently sup- port simultaneous operation of a virtual card reader, a virtual printer, and a virtual punch (in addition to the operator console) on the same VRBT process. RJS itself will support more than one reader, printer, and punch at each remote terminal, so the NETRJS protocol could easily be expanded in the future to allow more simultaneous I/O streams to each Network user.
私たちは、これらのNETRJS接続のひとりにチャンネルという用語を使用して、CCNに関して入力か出力にそれを指定するつもりです。 それぞれのデータ転送チャンネルは特定の仮想のリモートdev氷と同一視されています--カードリーダ、プリンタ、またはパンチ。 彼らが使用中であるだけである間、データ転送チャンネルはオープンでなければなりません、そして、異なったチャンネルは連続するか同時に、使用されるかもしれません。 NETRJSは現在、同じVRBTプロセスの上で仮想のカードリーダ、仮想のプリンタ、および仮想のパンチ(オペレータコンソールに加えた)のポート同時処理操作をすするでしょう。 RJS自身が各遠隔端末での1つ以上の読者、プリンタ、およびパンチを支えるので、将来、それぞれのNetworkユーザにより同時の入出力ストリームを許容するために容易にNETRJSプロトコルを広げることができました。
The remote user needs a local escape convention so he can send com- mands directly to his VRBT process. These local VRBT commands would allow selection of the files at his host which contain job streams to be sent to the server, and files to receive job output from the server. They would also allow the user to open data transfer chan- nels to the NETRJS server process, and to close these connections to free buffer space or abort a transmission.
彼が直接VRBTプロセスにcom- mandsを送ることができるように、リモート・ユーザーは地方のエスケープコンベンションを必要とします。 これらのローカルのVRBTコマンドは、彼のホストのジョブストリームを含むファイルの品揃えがサーバに送られるのを許容して、ファイルがサーバから仕事の出力を受け取るのを許容するでしょう。それらは、ユーザにNETRJSサーバプロセスにデータ転送chan- nelsを開いて、また、バッファ領域を解放するか、またはトランスミッションを中止するためにこれらの接続を終えさせるでしょう。
When a VRBT starts a session, it has a choice of two ICP sockets, depending upon whether it is an ASCII or an EBCDIC virtual terminal. An EBCDIC virtual terminal transmits and receives its data as tran- sparent streams of 8 bit bytes (since CCN is an EBCDIC installation). It is expected that a user at an ASCII installation, however, will want his VRBT declared ASCII; RJS will then translate the input stream from ASCII to EBCDIC and translate the printer stream back to ASCII. This will allow the user to employ his local text editor for preparing input to CCN and for examining output. The punch stream will always be transparent, for outputting "binary decks".
VRBTがセッションを始めるとき、それには、2個のICPソケットの選択があります、それがASCIIかそれともEBCDIC仮想端末であるかによって。 EBCDIC仮想端末は、8ビットのバイトのtran- sparentストリームとしてデータを送って、受け取ります(CCNがEBCDICインストールであるので)。 しかしながら、ASCIIインストールにおけるユーザがASCIIであると彼のVRBTを申告して欲しくなると予想されます。 RJSは次に、ASCIIからEBCDICまで入力ストリームを翻訳して、プリンタストリームをASCIIに翻訳して戻すでしょう。 これで、ユーザはCCNに入力を準備して、出力を調べるための地元のテキストエディタを使うことができるでしょう。 パンチストリームはいつも「2進のデッキ」を出力するのにわかりやすくなるでしょう。
It should be noted that the choice of code for the operator console connections is independent of declared terminal type; in particular, they always use ASCII under Telnet protocol, even from an EBCDIC VRBT.
接続の如何にかかわらずあるオペレータコンソールのためのコードの選択が端末のタイプを宣言したことに注意されるべきです。 特に、彼らはEBCDIC VRBTからさえTelnetプロトコルの下にASCIIをいつも使用します。
Braden [Page 4] RFC 189 Interim NETRJS Specifications July 1971
当座のNETRJS仕様ブレーデン[4ページ]RFC189 1971年7月
NETRJS protocol provides data compression, replacing repeated blanks or other characters by repeat counts. However, when the terminal id is assigned by CCN, a particular network terminal may be specified as using no data compression. In this case, NETRJS will simply truncate trailing blanks and send records in a simple "op code-length-data" form, called truncated format.
繰り返された空白か他のキャラクタを繰返し回数に取り替えて、NETRJSプロトコルはデータ圧縮を提供します。 しかしながら、端末のイドがCCNによって割り当てられるとき、特定のネットワーク端末はデータ圧縮を全く使用しないと指定されるかもしれません。 この場合、NETRJSは簡単な「オペコード長さのデータ」フォーム(呼ばれた端が欠けている形式)で引きずっている空白に単に先端を切らせて、記録を送るでしょう。
C. Starting and Terminating a Session
C。 始まって、セッションを終えます。
The remote user establishes a connection to RJS via the standard ICP from his socket U to socket 11 [sub] 10 (EBCDIC) or socket 13 [sub] 10 (ASCII) at host 1, IMP 1. If successful, the ICP results in a pair of connections which are in fact the NETRJS operator control connections.
リモート・ユーザーはホスト1に標準の彼のソケットUからソケット11[潜水艦]10の(EBCDIC)かソケット13[潜水艦]10(ASCII)までのICPを通してRJSに取引関係を築きます、IMP1。 うまくいくなら、ICPは事実上NETRJS操作員制御接続である接続の1組をもたらします。
Once the user is connected, he must enter a valid RJS signon command
("SIGNON terminal-id") through his console. RJS will normally ack-
nowledge signon with a console message; however, if RJS does not
recognize the terminal-id or has no available Line Handler for the
Network, it will indicate refusal by closing both operator connec-
tions. If the user attempts to open data transfer connections before
his signon command is accepted, the data transfer connections will be
refused by CCN with an error message to his console.
ユーザがいったん接続されるようになると、彼は彼のコンソールを通した有効なRJS signonコマンド(「SIGNONの端末のイド」)を入力しなければなりません。 RJSは通常コンソールメッセージがあるack- nowledge signonがそうするでしょう。 しかしながら、RJSに、端末のイドを認識しないか、またはNetworkのためのどんな利用可能な線Handlerもないと、それは、両方を閉じることによって、拒否を示すでしょう。オペレータconnec- tions。 ユーザが、彼のsignonコマンドを受け入れる前にデータ転送コネクションを開くのを試みると、データ転送コネクションはエラーメッセージでCCNによって彼のコンソールに拒否されるでしょう。
Suppose the operator input connection is socket S at CCN; S is the even number sent in the ICP. Then the other NETRJS channels have sockets at CCN with fixed relation to S, as shown in the table below. Until there is a suitable Network-wide solution to the problem of identity control on sockets, NETRJS will also require that the VRBT process use fixed socket offsets from his initial connection socket U. These are shown in the following table:
オペレータ入力接続がCCNのソケットSであると仮定してください。 SはICPで送られた偶数です。 そして、他のNETRJSチャンネルは表に示したように以下のSとの固定関係があるCCNにソケットを持っています。 また、ソケットの上にアイデンティティコントロールの問題への適当なNetwork全体の解決があるまで、NETRJSは、VRBTプロセス使用がU.Theseが以下のテーブルで見せられる彼の初期の接続ソケットからソケットオフセットを修理したのを必要とするでしょう:
Channel CCN Socket Remote Socket
(Server) (User)
チャンネルCCNソケットリモートなソケット(サーバ)(ユーザ)
Telnet / Remote Operator Console Input S U + 3 \
\ Remote Operator Console Output S + 1 U + 2 / Telnet
Data / Card Reader #1 S + 2 U + 5
Transfer < Printer #1 S + 3 U + 4
\ Punch #1 S + 5 U + 6
telnet/リモートなパンチ#1秒間+5円のリモートオペレータコンソール出力S+1U+2/telnetデータ/カードリーダ#1秒間+2U+5転送<プリンタ#1秒間+3U+4円のU+6オペレータコンソール入力S U+3円
Once the user is signed on, he can open data transfer channels and initiate input and output operations as explained in the following sections. To terminate the session, the remote user may close all connections. Alternatively, the user may enter a SIGNOFF command through his console; in this case, RJS will wait until the current job output streams are complete and then itself terminate the session by closing all connections.
ユーザ上がいったんサインされると、彼は、以下のセクションで説明されるようにデータ転送チャンネルを開けて、入出力操作を開始できます。 セッションを終えるために、リモート・ユーザーはすべての接続を終えるかもしれません。 あるいはまた、ユーザは彼のコンソールを通したSIGNOFFコマンドを入力するかもしれません。 この場合、現在のジョブ出力ストリームが終了していて、その時自体がすべての接続を終えることによってセッションを終えるまで、RJSは待つでしょう。
Braden [Page 5] RFC 189 Interim NETRJS Specifications July 1971
当座のNETRJS仕様ブレーデン[5ページ]RFC189 1971年7月
D. Input Operations
D。 入力操作
A job stream for submission to RJS at CCN is a series of logical records, each of which is a card image. A card image may be at most 80 characters long, to match the requirements of OS/360 for job input. The user can submit a "stack" of successive jobs through the card reader channel with no end-of-job indication between jobs; RJS recognizes the beginning of each new job by the appearance of a JOB card.
CCNのRJSへの服従のためのジョブストリームは一連の論理レコードです。それのそれぞれがカードイメージです。 長い間、カードイメージは、高々仕事の入力のためのOS/360の要件を合わせるためには80のキャラクタであるかもしれません。 ユーザは仕事の間のエンド・オブ・ジョブの指示なしでカードリーダチャンネルによる連続した仕事の「スタック」を提出できます。 RJSはJOBカードの外観でそれぞれの新しい仕事の始まりを認識します。
To submit a job or stack of jobs for execution at CCN, the remote user must first open the card reader channel. He signals his VRBT process to issue Init (local = U + 5, foreign = S + 2, size = 8). NETRJS, which is listening on socket S + 2, will normally return an RTS command, opening the channel. If, however, it should happen that all input buffer space within the CCN NCP is in use, the request will be refused, and the user should try again later. If the problem per- sists, call the Technical Liaison at CCN.
CCNの実行のための仕事の仕事かスタックを提出するために、リモート・ユーザーは最初に、カードリーダチャンネルを開けなければなりません。 彼は、Init(地方の=U+5、外国=S+2、サイズ=8)を発行するようにVRBTプロセスに合図します。 チャンネルを開けて、通常、NETRJS(ソケットS+2の上に聴いている)はRTSコマンドを返すでしょう。 しかしながら、CCN NCPの中のすべての入力バッファ領域が使用中であることが起こると、要求は拒否されるでしょう、そして、ユーザは後で再び試みるべきです。 問題である、-、sists、CCNでTechnical Liaisonに電話をしてください。
When the connection is open, the user can begin sending his job stream using the protocol defined in Appendix A. For each job suc- cessfully spooled, the user will receive a confirming message on his console. At the end of the stack, he must send an End-of-Data tran- saction to initiate processing of the last job. NETRJS will then close the channel (to avoid holding buffer space unnecessarily). At any time during the session, the user can re-open the card reader channel and transmit another job stack. He can also terminate the session and sign on later to get his output.
接続がオープンであるときに、ユーザは、各仕事のsuc- cessfullyがスプールしたAppendix A.Forで定義されたプロトコルを使用することで彼のジョブストリームを送り始めることができて、ユーザは彼のコンソールに関する確認メッセージを受け取るでしょう。 スタックの端に、彼は、最後の仕事の処理を開始するためにデータのEnd tran- sactionを送らなければなりません。 そして、NETRJSはチャンネル(不必要にバッファ領域を保持するのを避ける)を閉じるでしょう。 いつでも、セッションの間、ユーザは、カードリーダチャンネルを再開させて、別のジョブスタックを伝えることができます。 彼は、また、セッションを終えて、後で彼の出力を手に入れるのを署名の上雇うことができます。
The user can abort the card reader channel at any time by closing the channel (his socket S + 2). NETRJS will then discard the last par- tially spooled job. If NETRJS finds an error (e.g., transaction sequence number error or a dropped bit), it will abort the channel by closing the connection prematurely, and also inform the user via his console that his job was discarded (thus solving the race condition between End-of-Data and aborting). The user needs to retransmit only the last job. However, he could retransmit the entire stack (although it would be somewhat wasteful) since the CCN operating sys- tem enforces job name uniqueness by immediately "flushing" jobs with names already in the system.
ユーザは、いつでも、チャンネル(彼のソケットS+2)を閉じることによって、カードリーダチャンネルを堕胎できます。 そして、NETRJSは最後の平価のtiallyのスプールさせられた仕事を捨てるでしょう。 NETRJSが間違いを見つけると(例えば、トランザクション一連番号誤りか下げられたビット)、それは、早まって接続を終えることによってチャンネルを堕胎して、また、彼のコンソールを通して彼の仕事が捨てられたことをユーザに知らせるでしょう(その結果、データのEndと中止の間の競合条件を解決します)。 ユーザは、最後の仕事だけを再送する必要があります。 しかしながら、CCN操作sys- temがすぐにまでにシステムで名前で既に仕事を「洗い流し」ながらジョブ名のユニークさを実施するので、彼は全体のスタック(それはいくらか無駄でしょうが)を再送できました。
If the user's process, NCP, or host, or the Network itself fails dur- ing input, RJS will discard the job being transmitted. A message informing the user that this job was discarded will be generated and sent to him the next time he signs on. On the other hand, those jobs whose receipt have been acknowledged on the operator's console will not be affected by the failure, but will be executed by CCN.
ユーザのプロセス、NCP、ホスト、またはNetwork自身がdur- ing入力に失敗すると、RJSは伝えられる仕事を捨てるでしょう。 この仕事が捨てられたことをユーザに知らせるのを、彼が雇われる次の時に彼に生成して、送るというメッセージ。 他方では、領収書がオペレーターズコンソールの上で受け取ったことを知らせられたそれらの仕事は、失敗で影響を受けませんが、CCNによって実行されるでしょう。
Braden [Page 6] RFC 189 Interim NETRJS Specifications July 1971
当座のNETRJS仕様ブレーデン[6ページ]RFC189 1971年7月
E. Output Operations
E。 出力操作
The user may wait to set up a virtual printer (or punch) and open its channel until a STATUS message on his console indicates output is ready; or he may leave the output channel(s) open during the entire session, ready to receive output whenever it becomes available. He can also control which one of several available jobs is to be returned by entering appropriate operator commands.
ユーザは、仮想のプリンタ(パンチする)をセットアップして、彼のコンソールに関するSTATUSメッセージが、出力が準備ができているのを示すまでチャンネルを開けるのを待つかもしれません。 または、彼は出力チャネルを全体のセッションの間、開いて、利用可能になるときはいつも、出力を受け取る準備ができているままにするかもしれません。 また、彼は、適切なオペレータコマンドを入力することによって返すためにいくつかの利用可能な仕事の1つがどれであるかを制御できます。
To be prepared to receive printer (or punch) output from his jobs, the user site issues Init (local = U + 4 (U + 6), foreign = S + 3 (S + 5), size = 8), respectively. NETRJS is listening on these sockets and should immediately return an STR. However, it is possible that because of software problems at CCN, RJS will refuse the connection and a CLS will be returned; in this case, try again or call the Technical Liaison.
彼の仕事からプリンタ(パンチする)出力を受け取るように準備されるには、ユーザの現場はそれぞれ、Init(地方の=U+4(U+6)、外国=S+3(S+5)、サイズ=8)を発行します。 NETRJSはこれらのソケットの上に聴いていて、すぐに、STRを返すはずです。 しかしながら、CCNのソフトウェアの問題のために、RJSが接続を拒否するのが、可能であり、CLSを返すでしょう。 この場合、再試行するか、またはTechnical Liaisonに電話をしてください。
When RJS has output to send to a particular (virtual) terminal and a corresponding open output channel, it will send the output as a series of logical records using the protocol in Appendix A. The first record will consist of the job name (8 characters) followed by a comma and then the ID string from the JOB card (if any). In the printer stream, the first column of each record will be an ASA car- riage control character (see Appendix C); the punch output stream will never contain carriage control characters.
RJSに特定(仮想の)の端末と対応する開いている出力チャネルに送る出力があるとき、最初の記録がそうするAppendix A.でプロトコルを使用する一連の論理レコードがコンマと次に、IDストリングがJOBカード(もしあれば)から支えたジョブ名(8つのキャラクタ)から成るとき、それは出力を送るでしょう。 プリンタの流れに、それぞれの最初のコラムはASA車がriage制御文字であるつもりであったなら記録します(Appendix Cを見てください)。 パンチ出力ストリームはキャリッジ制御文字を決して含まないでしょう。
NETRJS will send an End-of-Data transaction and then close an output channel at the end of the output for each complete batch job; the remote site must then send a new RFC (and ALL) to start output for another job. 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 on the operator input channel (see Appendix D).
NETRJSはデータのEndに取引を送って、次に、それぞれの完全なバッチ・ジョブのための出力の端に出力チャネルを閉じるでしょう。 そして、リモートサイトは、別口の仕事のための出力を始動するために、新しいRFC(すべて)を送らなければなりません。 これは仕事の中で出力を壊さないで各仕事のための新しいファイルを割り当てる機会をリモートサイトに与えます。 リモートサイトのユーザが取り消したがっている、(バックスペースキーを押して印字位置を一字分戻ってください、延期、)、特定の仕事の出力、彼はオペレータ入力チャンネルで適切なRJSコマンドを入力します(Appendix Dを見てください)。
A virtual printer in NETRJS has 254 columns, exclusive of carriage control; RJS will send up to 255 characters of a logical record it finds in a SYSOUT data set. If the user wishes to reject or fold records longer than some smaller record size, he can do so in his VRBT process.
NETRJSの仮想のプリンタには、改行制御を除いて254のコラムがあります。 RJSはそれがSYSOUTデータセットで見つける論理レコードの最大255のキャラクタを送るでしょう。 ユーザが何らかのよりわずかなレコード・サイズより長い間記録を拒絶したいか、または折り重ねたいなら、彼は彼のVRBTの過程でそうすることができます。
If RJS encounters a permanent I/O error in reading the disk data set, it will notify the user via his console, skip forward to the next set of system messages or SYSOUT data set in the same job, and continue. In the future, RJS may be changed to send a Lost Data marker within the data stream as well as a console message to the user. In any case, the user will receive notification of termination of output data transfer for each job via messages on his console.
RJSがディスクデータセットを読む際に永久的な入出力エラーに遭遇すると、それは、彼のコンソールを通してユーザに通知して、前方に同じ仕事におけるシステムメッセージかSYSOUTデータセットの次のセットまでスキップして、続くでしょう。 将来、ユーザへのコンソールメッセージと同様にデータ・ストリームの中でLost Dataマーカーを送るためにRJSを変えるかもしれません。 どのような場合でも、ユーザは彼のコンソールに関するメッセージで各仕事のための出力データ転送の終了の通知を受け取るでしょう。
Braden [Page 7] RFC 189 Interim NETRJS Specifications July 1971
当座のNETRJS仕様ブレーデン[7ページ]RFC189 1971年7月
If the user detects an error in the stream, he can issue a Backspace (BSP) command from his console to repeat the last "page" of output, or a Restart (RST) command to repeat from last SYSOUT data set or the beginning of the job, or he can abort the channel by closing his socket. If he aborts the channel, RJS will simulate a Backspace com- mand, and when the user re-opens the channel the job will begin transmission again from an earlier point in the same data set. This is true even if the user terminates the current session first, and re-opens the channel in a later session; RJS saves the state of its output streams. However, before re-opening the channel he can defer this job for later output, restart it at the beginning, or cancel its output (see Appendix D). Note that aborting the channel is only effective if RJS has not yet sent the End-of-Data transaction.
ユーザが流れで誤りを検出するなら、出力の最後の「ページ」、最後のSYSOUTデータセットから繰り返すRestart(RST)コマンドまたは仕事の始まりを繰り返すために彼のコンソールからBackspace(BSP)にコマンドを発行できますか、または彼は、彼のソケットを閉じることによって、チャンネルを堕胎できます。 彼がチャンネルを堕胎すると、RJSはBackspace com- mandをシミュレートするでしょう、そして、ユーザがチャンネルを再開させると、仕事は再び同じデータセットで以前のポイントからトランスミッションを始めるでしょう。 ユーザが最初に現在のセッションを終える、後のセッションのときにチャンネルを再開させても、これは本当です。 RJSは出力ストリームの事情を節約します。しかしながら、チャンネルを再開させる前に、彼は、後の出力のためにこの仕事を延期するか、始めにそれを再開するか、または出力を中止できます(Appendix Dを見てください)。 RJSがまだデータのEnd取引を送らない場合にだけチャンネルを堕胎するのが有効であることに注意してください。
If the user's process, NCP, or host, or the Network itself fails dur- ing an output operation, RJS will act as if the channel had been aborted and the user signed off. In no case should a user lose out- put from NETRJS.
ユーザの過程、NCP、ホスト、またはNetwork自身がまるでチャンネルが堕胎されたかのように出力操作、RJSが行動して、ユーザがサインしたdur- ingに失敗するなら。 ユーザはNETRJSから置かれたアウトを決して、失うべきではありません。
Braden [Page 8] RFC 189 Interim NETRJS Specifications July 1971
当座のNETRJS仕様ブレーデン[8ページ]RFC189 1971年7月
Appendix A
付録A
Data Transfer Protocol in NETRJS
NETRJSのデータ転送プロトコル
1. Introduction
1. 序論
The records in the data transfer channels (for virtual card reader, printer, and punch) are generally grouped into _transactions_ pre- ceded by headers. The transaction header includes a sequence number and the length of the transaction. Network byte size must be 8 bits in these data streams.
一般に、データ転送チャンネル(バーチャルカード読者、プリンタ、およびパンチのための)による記録は_ヘッダーによってあらかじめ割譲された取引_に分類されます。 取引ヘッダーは取引の一連番号と長さを入れます。 ネットワークバイトサイズはこれらのデータ・ストリームの8ビットでなければなりません。
A transaction is the unit of buffering within the Model 91 software. Internal buffers are 880 bytes. Therefore, CCN cannot transmit or receive a single transaction larger than 880 bytes. Transactions can be as short as one record; however, those sites which are concerned with efficiency should send transactions as close as possible to the 880 byte limit.
取引はModel91の中でソフトウェアをバッファリングするユニットです。 内部のバッファは880バイトです。 したがって、CCNは880バイトより大きい単一取引を伝えることができませんし、受けることができません。 取引は1つの記録と同じくらい短いことができます。 しかしながら、効率に関するそれらのサイトはできるだけ880バイトの限界の近くに取引を送るべきです。
There is no necessary connection between physical message boundaries
and transactions ("logical messages"); the NCP can break the "logical
message" arbitrarily into physical messages. At CCN we will choose
to have each logical message start a new physical message, so the NCP
can send the last part of each message without waiting for an expli-
cit request, but a remote site is not required to follow this conven-
tion.
物理メッセージ限界と取引(「論理メッセージ」)とのどんな必要な関係もありません。 NCPは任意に「論理メッセージ」を物理メッセージに細かく分けることができます。 CCNでは、私たちは、各論理メッセージに新しい物理メッセージを始めさせるのを選ぶつもりですが、expli- cit要求を待たないで、したがって、NCPはそれぞれのメッセージの最後の部分を送ることができますが、リモートサイトは、このconven- tionに続くのに必要ではありません。
Each logical record within a transaction begins with an "op code" byte which contains the channel identification, so its value is unique to each channel but constant within a channel. This choice provides a convenient way to verify bit synchronization at the receiver, and also allows an extension in the future to true "multi- leaving" (i.e., multiplexing all channels within one connection in each direction).
取引の中の各論理レコードはチャネル識別を含む「オペコード」バイトで始まりますが、したがって、値は、各チャンネルにユニークですが、チャンネルの中に一定です。 この選択は、受信機でビット同期について確かめる便利な方法を提供して、また、将来、本当の「マルチ退出」に拡大を許します(すなわち、1つの接続の中で各方向にオール・チャンネルを多重送信します)。
The only provisions for transmission error detection in the current NETRJS protocol are (1) this "op code" byte to verify bit synchroni- zation and (2) the transaction sequence number. At the urging of Crowther, we favor putting an optional 16 bit check sum in the unused bytes of the second-level header. It is currently assumed that if an error is detected then the channel is to be aborted and the entire transmission repeated. To provide automatic retransmission we would have to put in reverse channels for ACK/NAK messages.
現在のNETRJSプロトコルにおける伝送エラー検出のための唯一の条項が(2) ビットsynchroni- zationと取引一連番号について確かめる(1) この「オペコード」バイトです。 クラウザーの衝動のときに、私たちは、第2レベルヘッダーの未使用のバイトに16ビットの任意のチェックサムを入れるのを支持します。 現在、誤りが検出されるならチャンネルが堕胎されることになっていて、全体のトランスミッションが繰り返されたと思われます。 私たちが入れなければならない自動「再-トランスミッション」を提供するには、ACK/NAKメッセージのためにチャンネルを逆にしてください。
Braden [Page 9] RFC 189 Interim NETRJS Specifications July 1971
当座のNETRJS仕様ブレーデン[9ページ]RFC189 1971年7月
2. Character Sets
2. 文字コード
For an ASCII VRBT, NETRJS will map ASCII in the card reader stream into EBCDIC, and re-map the printer stream to ASCII, by the following rules:
ASCII VRBTに関しては、NETRJSはカードリーダストリームにおけるASCIIをEBCDICに写像して、プリンタの流れをASCIIに再写像するでしょう、以下の規則で:
1. One-to-one mapping between the three ASCII characters | ~ \
which are not in EBCDIC, and the three EBCDIC characters
[vertical bar, not-sign and cent-sign] (respectively) which
are not in ASCII.
1. 1〜1に、3つの間でASCII文字を写像します。| ~ EBCDICにない\、およびASCIIにはいない3人のEBCDlC文字[縦棒、サインでなく、およびセント記号](それぞれ)。
2. The other six ASCII graphics not in EBCDIC will be
translated on input to an EBCDIC question mark (?).
2. 他の6つのASCIIグラフィックスは入力のときにEBCDICでEBCDIC疑問符(?)に翻訳されないでしょう。
3. The ASCII control DC3 (the only one not in EBCDIC) will be
mapped into and from the EBCDIC control TM.
3. ASCIIコントロールDC3(EBCDICでないところの唯一無二)はTMの中と、そして、EBCDICコントロールTMから写像されるでしょう。
4. The EBCDIC characters not in ASCII will be mapped in the
printer stream into the ASCII question mark.
4. EBCDlC文字はプリンタの流れでASCII疑問符にASCIIで写像されないでしょう。
3. Meta-Notation
3. メタ記法
The following description of the NETRJS data transfer protocol uses a formal notation derived from that proposed in RFC #31 by Bobrow and Sutherland. (The NETRJS format is also shown diagramatically in Figure 2.)
NETRJSデータ転送プロトコルの以下の記述はRFC#31でBobrowとサザーランドによって提案されたそれから得られた正式な記法を使用します。 (また、図2のdiagramaticallyはNETRJS形式に見せられます。)
The derived notation is both concise and easily readable, and we recommend its use for Network documentation. The notation consists of a series of productions for bit string variables whose names are capitalized. Each variable name which represents a fixed length field is followed by the length in bits (e.g., SEQNUMB(16)). Numbers enclosed in quotes are decimal, unless qualified by a leading X meaning hex. Since each hex digit is 4 bits, the length is not shown explicitly in hex numbers. For example, '1'(8) and X'FF' both represent a string of 8 one bits. The meta-syntactic operators are:
派生している記法は、簡潔であって、かつ容易に読み込み可能です、そして、私たちはNetworkドキュメンテーションの使用を推薦します。 記法は名前が大文字で書かれるビット列変数のための一連の創作から成ります。 ビットの長さは固定長電界を表す各変数名のあとに続いています。(例えば、SEQNUMB(16))。 主なX意味十六進法によって資格がない場合、引用文に同封された数は10進です。 それぞれの十六進法ケタが4ビットであるので、長さは十六進法番号で明らかに示されません。 例えば、'1'の(8)とX'FF'はともに一連の8を1ビット表します。 メタ構文のオペレータは以下の通りです。
| :alternative string
[ ] :optional string
( ) :grouping
+ :catenation of bit strings
| ビット列の:alternativeストリング[ ]:optionalストリング( ):grouping+:catenation
The numerical value of a bit string (interpreted as an integer) is symbolized by a lower case identifier preceding the string expression and separated by a colon. For example, in "i:FIELD(8)", i symbolizes the numeric value of the 8 bit string FIELD.
しばらくストリング(整数を解釈する)の数値は、ストリング表現に先行する小文字識別子によって象徴されていて、コロンによって切り離されます。 例えば、「i: 分野(8)」では、私は8ビット列FIELDの数値を象徴します。
Braden [Page 10] RFC 189 Interim NETRJS Specifications July 1971
当座のNETRJS仕様ブレーデン[10ページ]RFC189 1971年7月
Finally, we use Bobrow and Sutherland's symbolism for iteration of a sub-string: (STRING-EXPRESSION = n); denotes n occurrences of STRING EXPRESSION, implicitly catenated together. Here any n >= 0 is assumed unless n is explicitly restricted.
最終的に、私たちはサブストリングの繰り返しにBobrowとサザーランドのシンボリズムを使用します: (STRING-EXPRESSION=n)。 それとなく一緒にcatenatedされたSTRING EXPRESSIONのn発生を指示します。 ここで、nが明らかに制限されない場合、どんなn>=0も想定されます。
4. Protocol Definition
4. プロトコル定義
STREAM <-- (TRANSACTION = n) + [END-OF-DATA]
STREAM<--(TRANSACTIONはnと等しいです)+[データの終わり]
That is, STREAM, the entire sequence of data on a particular open channel, is a sequence of n TRANSACTIONS followed by an END-OF-DATA marker (omitted if the sender aborts the channel).
すなわち、STREAM(特定の開水路に関するデータの全体の系列)はEND-OF-DATAマーカー(送付者がチャンネルを堕胎するなら、省略される)によって続かれたn TRANSACTIONSの系列です。
TRANSACTION <-- THEAD(72) + (RECORD = r) + ('0'(1) = f)
TRANSACTION<--THEAD(72)+(RECORDはrと等しいです)+('0'(1)=f)
That is, a transaction consists of a 72 bit header, r records, and f filler bits.
すなわち、取引は72ビットのヘッダー、r記録、およびfフィラービットから成ります。
THEAD <-- X'FF' + f:FILLER(8) + SEQNUMB(16) + LENGTH(32) + X'00'
THEAD<--X'FF'+f: フィラーの(8)+SEQNUMB(16)+長さの(32)+X'00'
Transactions are to be consecutively numbered in the SEQNUMB field, starting with 0 in the first transaction after the channel is (re-) opened. The 32 bit LENGTH field gives the total length in bits of the r RECORD's which follow. For convenience, the using site may add f additional filler bits at the end of the transaction to reach a convenient word boundary on his machine; the value f is also transmitted in the FILLER field of THEAD.
取引はSEQNUMB分野で連続して付番されることです、チャンネルが始まった後に、最初の取引で0から始まって(再、)、開かれます。 32ビットのLENGTH分野は続くr RECORDのもののビットの全長を与えます。 便宜のために、使用サイトはそうするかもしれません。取引の終わりにf追加フィラービットを加えて、彼のマシンの上の便利な語境界に達してください。 また、値fはTHEADのFILLER分野で送られます。
RECORD <-- COMPRESSED | TRUNCATED
<--圧縮されると記録してください。| 先端を切られます。
RJS will accept intermixed RECORD's which are COMPRESSED or TRUNCATED in an input stream. RJS will send one or the other format in the printer and punch streams to a given VRBT; the choice is determined when CCN establishes a terminal id.
RJSは入力ストリームでCOMPRESSEDかTRUNCATEDである混ぜられたRECORDのものを受け入れるでしょう。 RJSはプリンタとパンチストリームで1かもう片方の形式を与えられたVRBTに送るでしょう。 CCNが端末のイドを確立するとき、選択は決定しています。
COMPRESSED <-- '2'(2) + DEVID(6) + (STRING = p) + '0'(8)
COMPRESSED<--'2'(2)+DEVID(6)+(STRINGはpと等しいです)+'0'(8)
STRING <-- ('6'(3) + i:DUPCOUNT(5))
This form represents a string of i
consecutive blanks
STRING<--、('6'(3)+i: これが形成するDUPCOUNT(5))は一連のi連続した空白を表します。
('7'(3) + i:DUPCOUNT(5) + TEXTBYTE(8))
This form represents string of i consecutive
duplicated of TEXTBYTE.
('7'(3)+i: これが形成するDUPCOUNT(5)+TEXTBYTE(8))はTEXTBYTEについてコピーされたi連続することのストリングを表します。
Braden [Page 11] RFC 189 Interim NETRJS Specifications July 1971
当座のNETRJS仕様ブレーデン[11ページ]RFC189 1971年7月
('2'(2) + j:LENGTH(6) + (TEXTBYTE(8) = j))
This form represents a string of j
characters.
('2'(2)+j: LENGTH(6)+(TEXTBYTE(8)はjと等しいです)) このフォームは一連のjキャラクタの代理をします。
The first two alternatives above in the STRING production begin with count bytes chosen to be distinguishable from the (currently defined) Telnet control characters. In a Telnet stream, the third count byte would not be needed. This is irrelevant to the current NETRJS, but it would allow the use of compression within a Telnet data stream.
カウントバイトが(現在、定義されています)のtelnet制御文字から区別可能になるように選ばれている状態で、STRING生産における上の最初の2つの選択肢が始まります。 Telnetの流れでは、3番目のカウントバイトは必要でないでしょう。 これは現在のNETRJSと無関係ですが、それはTelnetデータ・ストリームの中で圧縮の使用を許すでしょう。
TRUNCATED <-- '3'(2) + DEVID(6) + n:COUNT(8) + (TEXTBYTE(8) = n)
端が欠けている<--'3'(2)+DEVID(6)+n: (8) +を数えてください。(TEXTBYTE(8)=n)
DEVID(6) <-- DEVNO(3) + t:DEVTYPE(3)
DEVID(6)<--DEVNO(3)+t: DEVTYPE(3)
DEVID identifies a particular virtual device, i.e.,
it identifies a channel. DEVTYPE specifies the type
of device, as follows:
DEVIDは特定の仮想の装置を特定します、すなわち、それがチャンネルを特定します。 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(3) identifies the particular device of type t
at this remote site; at present only DEVNO = 0 is
possible.
DEVNO(3)はこのリモートサイトでタイプtの特定の装置を特定します。 現在のところ、DEVNOだけ=0は可能です。
END-OF-DATA <-- X'FE'
Signals end of job (output) or job stack (input).
END-OF-DATA<--X'FE'Signalsエンド・オブ・ジョブ(出力)かジョブスタック(入力)。
Braden [Page 12] RFC 189 Interim NETRJS Specifications July 1971
当座のNETRJS仕様ブレーデン[12ページ]RFC189 1971年7月
APPENDIX B
付録B
Telnet for VRBT Operator Console
VRBTオペレータコンソールのためのtelnet
The remote operator console connections use the ASCII Telnet protocol as in RFC #158. Specifically:
リモートオペレータコンソール接続はRFC#158のようにASCII Telnetプロトコルを使用します。 明確に:
1) The following one-to-one character mappings are used for the
three EBCDIC graphics not in ASCII:
1) 以下の1〜1つのキャラクタマッピングがASCIIでないのにおける3つのEBCDICグラフィックスに使用されます:
ASCII
in Telnet NETRJS
telnet NETRJSのASCII
| [vertical bar]
~ [not-sign]
\ [cent-sign]
| [縦棒]~[サインしません]\[セント記号]
2) Initially all Telnet control characters will be ignored. In the
future we will implement the Telnet Break facility to allow a
remote user to terminate extensive console output from a
command.
2) 初めは、すべてのTelnet制御文字が無視されるでしょう。 将来、私たちは、リモート・ユーザーがコマンドからの大規模なコンソール出力を終えるのを許容するためにTelnet Break施設を実行するつもりです。
3) An operator console input line which exceeds 133 characters
(exclusive of CR LF) will be truncated by NETRJS.
3) 133のキャラクタ(CR LFを除いた)を超えているオペレータコンソール入力行はNETRJSによって先端を切られるでしょう。
4) NETRJS will accept BS to delete a character, and CAN to delete
the current line. The sequence CR LF terminates each input and
output line. HT will be translated to a single space in RJS.
All other ASCII control characters will be ignored. NETRJS will
translate the six ASCII graphics with no equivalent in EBCDIC
into the character question mark ("?") on input.
4) NETRJSはキャラクタを削除するBS、および現在行を削除するCANを受け入れるでしょう。 系列CR LFはそれぞれの入出力線を終えます。 HTはRJSのシングルスペースに翻訳されるでしょう。 他のすべてのASCII制御文字が無視されるでしょう。 NETRJSは入力のときにEBCDICで同等物なしでキャラクタ疑問符(“?")に6つのASCIIグラフィックスを翻訳するでしょう。
Braden [Page 13] RFC 189 Interim NETRJS Specifications July 1971
当座のNETRJS仕様ブレーデン[13ページ]RFC189 1971年7月
APPENDIX C
付録C
Carriage Control
改行制御
The carriage control characters sent in a printer channel by NETRJS conform to IBM's extended USASI code, defined by the following table:
プリンタチャンネルでNETRJSによって送られたキャリッジ制御文字は以下のテーブルによって定義されたIBMの拡張USASIコードに従います:
CODE ACTION BEFORE WRITING RECORD
記録を書く前のコード動作
blank Space one line before printing
0 Space two lines before printing
- Space three lines before printing
+ Suppress space before printing
1 Skip to channel 1
2 Skip to channel 2
3 Skip to channel 3
4 Skip to channel 4
5 Skip to channel 5
6 Skip to channel 6
7 Skip to channel 7
8 Skip to channel 8
9 Skip to channel 9
A Skip to channel 10
B Skip to channel 11
C Skip to channel 12
チャンネル1 2Skipに1Skipを印刷する前に、空白のSpace1は、11C Skipにチャンネル12にチャネルを開設するためにチャンネル10B Skipに9A Skipにチャネルを開設するためにチャンネル8 9Skipに7 8Skipにチャネルを開設するためにチャンネル6 7Skipに5 6Skipにチャネルを開設するためにチャンネル4 5Skipに3 4Skipにチャネルを開設するためにチャンネル2 3Skipにスペースを3が印刷の前で裏打ちする印刷--スペースの前に0Space two線を印刷する前に、裏打ちするか、または抑圧します。
Braden [Page 14] RFC 189 Interim NETRJS Specifications July 1971
当座のNETRJS仕様ブレーデン[14ページ]RFC189 1971年7月
APPENDIX D
付録D
Network/RJS Command Summary
ネットワーク/RJSコマンド概要
Terminal Control and Information Command
端末のコントロールと情報コマンド
SIGNON First command of a session; identifies VRBT by giving
its terminal id.
セッションのSIGNON Firstコマンド。 端末のイドを与えることによって、VRBTを特定します。
SIGNOFF Last command of a session; RJS waits for any data
transfer in progress to complete and then closes all
connections.
セッションのSIGNOFF Lastコマンド。 RJSは完成するためには進行中のどんなデータ転送も待っていて、次に、すべての接続を終えます。
STATUS Outputs on the remote operator console a complete
list, or a summary, of all jobs in the system for
this VRBT, with an indication of their processing
status in the Model 91.
リモートオペレータコンソールの上のSTATUS OutputsはこのVRBTのシステムにおけるそれらの処理状態のしるしがModel91にあるすべての仕事の全リスト、または概要です。
ALERT Outputs on the operator console the special "Alert"
message, if any, from CCN computer operator. The
Alert message is also automatically sent when the
user does a SIGNON, or whenever the message changes.
特別番組がCCNコンピュータオペレータからのもしあればメッセージを「警告する」オペレータコンソールの上のALERT Outputs。 また、ユーザがSIGNONをするか、またはメッセージが変化するときはいつも、自動的にAlertメッセージを送ります。
MSG Sends a message to CCN computer operator or to any
other RJS terminal (real or virtual). A message from
the computer operator or another RJS terminal will
automatically appear on the remote operator console.
CCNコンピュータオペレータ、または、いかなる他のRJS端末へのMSG Sends aメッセージ(本当の、または、仮想の)。 コンピュータオペレータか別のRJS端末からのメッセージはリモートオペレータコンソールの上に自動的に現れるでしょう。
Job Control and Routing Commands
ジョブ制御とルート設定命令
Under CCN's job management system, the default destination for output is the input source. Thus, a job submitted under a given VRBT will be returned to that VRBT (i.e., the same terminal id), unless the user's JCL overrides the default destination.
CCNのジョブ管理システムの下では、出力のためのデフォルトの目的地は入力ソースです。 したがって、そのVRBT(すなわち、同じ端末のイド)に与えられたVRBTの下で提出された仕事を返すでしょう、ユーザのJCLがデフォルトの目的地をくつがえさない場合。
RJS places print and punch output described for a particular remote terminal into either an Active Queue or a Deferred Queue. When the user opens his print or punch output channel, RJS immediately starts sending job output from the Active Queue, and continues this queue is empty. Job output in the Deferred Queue, on the other hand, must be called for by job name, (via a RESET command from the remote opera- tor) before RJS will send it. The Active/Deferred choice for output from a job is determined by the deferral status of the VRBT when the job is entered; the deferral status, which is set to the Active option when the user signs on, may be changed by the SET command.
RJS場所は、特定の遠隔端末のためにActive QueueかDeferred Queueのどちらかに説明された出力を、印刷して、パンチします。 ユーザが彼の印刷かパンチ出力チャネルを開くとき、RJSはすぐにActive Queueから仕事の出力を送り始めて、続きます。この待ち行列は空です。 他方では、ジョブ名でDeferred Queueでの仕事の出力を求めなければならない、(リモートオペラtorからのRESETコマンドを通した) 以前、RJSはそれを送るでしょう。 仕事が入られるとき、仕事からの出力のためのActive/延期された選択はVRBTの延期状態のそばで決定しています。 SETコマンドで延期状態(ユーザが雇われるときActiveオプションに設定される)を変えるかもしれません。
Braden [Page 15] RFC 189 Interim NETRJS Specifications July 1971
当座のNETRJS仕様ブレーデン[15ページ]RFC189 1971年7月
SET Allows the remote user to change certain properties
of his VRBT for the duration of the current session;
現在のセッションの持続時間のために彼のVRBTのある資産を変えるリモート・ユーザーのSET Allows。
(a) May change the default output destination to be
another (real or virtual) RJS terminal or the central
facility.
(a) 別の(本当であるか仮想)のRJS端末か中央の施設になるようにデフォルト出力の目的地を変えるかもしれません。
(b) May change the deferral status of the VRBT.
(b) VRBTの延期状態を変えるかもしれません。
DEFER Moves the print and punch output for a specified job
or set of jobs from the Active Queue to the Deferred
queue. If the job's output is in the process of
being transmitted over a channel, RJS aborts the
channel and saves the current output location before
moving the job to the Deferred Queue. A subsequent
RESET command will return it to the Active Queue with
an implied Backspace (BSP).
印刷とパンチが指定された仕事か1セットのActive QueueからDeferred待ち行列までの仕事のために出力したDEFERムーヴス。 チャンネルの上に伝えられることの途中に仕事の出力があるなら、RJSは、チャンネルを堕胎して、移行する前の経常産出高位置が仕事であることをDeferred Queueに救います。 その後のRESETコマンドは暗示しているBackspace(BSP)とActive Queueにそれを返すでしょう。
RESET Moves specified job(s) from Deferred to Active Queue
so they may be sent to user. A specific list of job
names or all jobs can be moved with one RESET
command.
RESETムーヴスがDeferredからActive Queueまでの仕事を指定したので、それらをユーザに送るかもしれません。 ジョブ名かすべての仕事の特定のリストを1つのRESETコマンドに動かすことができます。
ROUTE Re-routes output of specified jobs (or all jobs)
waiting in the Active and Deferred Queues for this
VRBT. The new destination may be any other RJS
terminal or the central facility.
ActiveとDeferred QueuesでこのVRBTを待つ指定された仕事(または、すべての仕事)のROUTE Re-ルート出力。 新しい目的地は、いかなる他のRJS端末か中央の施設であるかもしれません。
ABORT Cancels a job which was successfully submitted and
awaiting execution or is current executing in the
Model 91. If he cancelled job was in execution, all
output it produced ill be returned.
ABORTキャンセルは首尾よく提出していて、待ち実行であったかModel91での現在の実行である仕事です。 彼が取り消したなら、仕事は実行、それが起こしたすべての出力中でした。ほとんど返されません。
Output Stream Control Commands
出力ストリーム制御機能コマンド
BSP (BACKSPACE) "Backspaces" output stream within current sysout data
set. Actual amount backspaced depends upon sysout
blocking but is typically equivalent to a page on the
line printer.
現在のsysoutデータセットの中のBSP(BACKSPACE)が「バックスペースキーを押して印字位置を一字分戻る」という出力ストリーム。 実際の量がバックスペースキーを押して印字位置を一字分戻った、依存、sysoutでは、しかし、立ち塞がるのはラインプリンタの上の1ページに通常同等です。
CAN (CANCEL) (a) On an output channel, CAN causes the rest of the
output in the sysout data set currently being
transmitted to be omitted. Alternatively, may
omit the rest of the sysout data sets for the job
currently being transmitted; however, the remain-
ing system and accounting messages will be sent.
出力チャネルのCAN(キャンセル)(a)、CANは現在伝えられるsysoutデータセットにおける、出力の残りを省略させます。 あるいはまた、現在伝えられる仕事のためのsysoutデータセットの残りを省略するかもしれません。 しかしながら、残りingシステムと会計メッセージを送るでしょう。
Braden [Page 16] RFC 189 Interim NETRJS Specifications July 1971
当座のNETRJS仕様ブレーデン[16ページ]RFC189 1971年7月
(b) On an input channel, CAN causes RJS to ignore the
job currently being read. However, the channel
is not aborted as a result, and RJS will continue
reading in jobs on the channel.
現在、ありながら仕事を無視する原因RJSは、入力での(b)が精神を集中すると読むことができますか? しかしながら、チャンネルはその結果堕胎されません、そして、RJSはチャンネルの上に仕事で読み続けるでしょう。
(c) CAN can delete all sysout data sets for specified
job(s) waiting in Active or Deferred Queue.
(c) CANは、ActiveかDeferred Queueで待ちながら、指定された仕事のためのすべてのsysoutデータセットを削除できます。
RST (RESTART) (a) Restarts a specified output stream at the begin-
ning of the current sysout data set or, option-
ally, at the beginning of the job.
RST(RESTART)(a)が指定された出力ストリームを再開する、現在のsysoutデータセットのningを始めるか、または仕事の始めに同盟国にゆだねてください。
(b) Marks as restarted specified job(s) whose
transmission was earlier interrupted by system
failure or user action (e.g., DEFER command or
aborting the channel). When RJS transmits these
jobs again it will start at the beginning of the
partially transmitted sysout data set or, option-
ally, at the beginning of the job. This function
may be applied to jobs in either the Active or
the Deferred Queue; however, if the job was in
the Deferred Queue then RST also moves it to the
Active Queue. If the job was never transmitted,
RST has no effect other than this queue movement.
(b) 再開されるとしてのマークはトランスミッションが前にシステム障害によって中断された仕事かユーザ動作(例えば、DEFERコマンドかチャンネルを堕胎する)を指定しました。 RJSが部分的に伝えられたsysoutデータセットの始めに再びこれらの仕事を伝えるとき、始まるだろうか、またはオプションは同盟します、仕事の始めに。 この機能はActiveかDeferred Queueのどちらかでの仕事に打ち込まれるかもしれません。 しかしながら、仕事がDeferred Queueにあったなら、また、RSTはそれをActive Queueに動かします。 仕事が決して伝えられなかったなら、この待ち行列運動以外に、RSTは効き目がありません。
REPEAT Sends additional copies of the output of specified
jobs.
指定された仕事の出力のREPEAT Sends複本。
EAM Echoes the card reader stream back in the printer or
punch stream, or both.
カードリーダストリームがプリンタかパンチストリームで支持するEAMエコーズ、または両方。
Braden [Page 17] RFC 189 Interim NETRJS Specifications July 1971
当座のNETRJS仕様ブレーデン[17ページ]RFC189 1971年7月
+---------------------------------+
| RJS |
+---------------------------------+
^ | ^ | |
| v | v v
+------------------------------+
CCN -- Server | |
| NETRJS |
+------------------------------+
^ | ^ | |
| v | v v
+----------+ +---------------+
| TELNET | | Data Xfer | (server)
| Server | | 3rd Level |
+----------+ +---------------+
^ | ^ | |
---------------------|-----|----------|-----|-----|-----------------
O | O | | | |
p | p | C| C| C|
e I | e O| I h| O h| P h|
ARPA r n | r u| n a| u a| u a|
a p | a t| p n| t n| n n|
Network t u | t p| u n| p n| c n|
o t | o u| t e| u e| h e|
r | r t| l| t l| l|
---------------------|-----|----------|-----|-----|-----------------
| | | | |
| V | V V
+----------+ +---------------+
| TELNET | | Data Xfer | (user)
| Server | | 3rd Level |
+----------+ +---------------+
Remote ^ ^ | |
/ "Virtual | | |
User / Remote Batch | V V
/ Terminal" +------------------+
/ | |
V | NETRJS |
+---------+ | User |
/ |<------------->| Process |
/ Console | | |
+____________| +------------------+
^ | |
| V V
(file) (file) (file)
+---------------------------------+ | RJS| +---------------------------------+ ^ | ^ | | | v| v対+------------------------------+CCN--サーバ| | | NETRJS| +------------------------------+ ^ | ^ | | | v| v対+----------+ +---------------+ | telnet| | データXfer| (サーバ) | サーバ| | 第3レベル| +----------+ +---------------+ ^ | ^ | | ---------------------|-----|----------|-----|-----|----------------- O| O| | | | p| p| C| C| C| e I| e O| I h| ○ h| P h| ARPA r n| r u| n a| u a| u a| p| t| p n| t n| n n| t uをネットワークでつないでください。| t p| u n| p n| c n| o t| o u| t e| u e| h e| r| r t| l| t l| l| ---------------------|-----|----------|-----|-----|----------------- | | | | | | V| +に対するV----------+ +---------------+ | telnet| | データXfer| (ユーザ) | サーバ| | 第3レベル| +----------+ +---------------+ リモート^ ^| | 「仮想/です」。| | | ユーザ/リモートバッチ| 「V V/端末」+------------------+ / | | V| NETRJS| +---------+ | ユーザ| / | <、-、-、-、-、-、-、-、-、-、-、-、--、>| プロセス| /コンソール| | | +____________| +------------------+ ^ | | | V V(ファイル)(ファイル)(ファイル)
FIGURE 1. SCHEMATIC OF NETRJS OPERATION
図1 NETRJS操作では、概要です。
Braden [Page 18] RFC 189 Interim NETRJS Specifications July 1971
当座のNETRJS仕様ブレーデン[18ページ]RFC189 1971年7月
+------+ +------+ +-----------+ +---------------------+
TRANSACTION <--> | X'FF'| |Filler| |Sequence | | Data Length |
| | | Count| | Number | | in bits |
+------+ +------+ +-----------+ +---------------------+
+------+
| X'00'| { RECORD } *
| |
+------+
+------+ +------+ +-----------+ +---------------------+ トランザクション<-->。| X'FF'| |フィラー| |系列| | データの長さ| | | | カウント| | 数| | ビットで| +------+ +------+ +-----------+ +---------------------+ +------+ | X'00'| *を記録してください。| | +------+
<---- n text bytes ------>
+--+-----+ +--------+ +--------+ +--------+
TRUNCATED <--> |11|Devid| | n (8) | | Text | . . . | Text |
RECORD | | (6) | | | | (8) | | (8) |
+--+-----+ +--------+ +--------+ +--------+
<。---- nテキストバイト------>+--+-----+ +--------+ +--------+ +--------+ 端が欠けている<-->。|11|Devid| | n(8)| | テキスト| . . . | テキスト| 記録| | (6) | | | | (8) | | (8) | +--+-----+ +--------+ +--------+ +--------+
/ \
| +---+----+ | *
| |110| n | (n blanks) |
| | |(5) | |
| +---+----+ |
| |
+--+-----+ / +---+----+ +--------+ |
COMPRESSED<--> |10|Devid|< |111| n | |Char- | (n replications |
RECORD | | (6) | \ | |(5) | | acter | of "Character") |
+--+-----+ | +---+----+ +--------+ |
| |
| +--+-----+ +--------+ +--------+ |
| |10| n | | Text | . . .| Text | |
| | | (6) | | (8) | | (8) | |
| +--+-----+ +--------+ +--------+ |
\ /
+------+
| X'00'|
| |
+------+
/ \ | +---+----+ | * | |110| n| (n空白) | | | |(5) | | | +---+----+ | | | +--+-----+ / +---+----+ +--------+ | 圧縮された<-->。|10|Devid|<| 111| n| |炭| (| RECORD| | (6)| \| | (5)| | n模写acter|、「キャラクター」) | +--+-----+ | +---+----+ +--------+ | | | | +--+-----+ +--------+ +--------+ | | |10| n| | テキスト| . . . | テキスト| | | | | (6) | | (8) | | (8) | | | +--+-----+ +--------+ +--------+ | \ / +------+ | X'00'| | | +------+
FIGURE 2. DATA TRANSFER PROTOCOL IN NETRJS
図2 NETRJSのデータ転送プロトコル
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Tony Hansen 11/98 ]
[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][トニー・ハンセン11/98によるオンラインRFCアーカイブへの]
Braden [Page 19]
ブレーデン[19ページ]
一覧
スポンサーリンク
