RFC740 日本語訳
0740 NETRJS Protocol. R.T. Braden. November 1977. (Format: TXT=38833 bytes) (Obsoletes RFC0599) (Status: HISTORIC)
プログラムでの自動翻訳です。
RFC一覧
英語原文
RFC 740 RTB 42423 22 Nov 77 NETRJS Protocol
RFC740RTB42423 1977年11月22日のNETRJSプロトコル
Network Working Group R. Braden Request for Comments: 740 UCLA-CCN NIC: 42423 22 November 1977 Obsoletes: 189, 599
コメントを求めるワーキンググループR.ブレーデン要求をネットワークでつないでください: 740UCLA-CCN NIC: 42423 1977年11月22日は以下を時代遅れにします。 189, 599
NETRJS PROTOCOL
NETRJSプロトコル
A. Introduction
A。 序論
NETRJS, a private protocol for remote job entry service, was defined
and implemented by the UCLA Campus Computing Network (CCN) for batch
job submission to an IBM 360 Model 91. CCN's NETRJS server allows a
remote user, or a daemon process working in behalf of a user, to
access CCN's RJS ("Remote Job Service") subsystem. RJS provides
remote job entry service to real remote batch (card reader/line
printer) terminals over direct communications lines as well as to the
ARPANET.
NETRJS(リモートジョブエントリサービスのための個人的なプロトコル)はIBM360Model91へのバッチジョブ依頼のためにUCLA Campus Computing Network(CCN)によって定義されて、実装されました。 CCNのNETRJSサーバはリモート・ユーザー、またはユーザのためにCCNのRJS(「リモート・ジョブサービス」)サブシステムにアクセスするために働いているデーモンプロセスを許容します。 RJSはアルパネットに関して本当のリモートバッチ(カードリーダ/ラインプリンタ)端末に対するリモートジョブエントリサービスをまた、ダイレクトコミュニケーション系列の上に提供します。
A batch user at a remote host needs a NETRJS user process to communicate with the NETRJS server at the batch host. An active NETRJS user process simulates a "Virtual Remote Batch Terminal", or "VRBT".
リモートホストのバッチユーザは、バッチホストのNETRJSサーバとコミュニケートするためにNETRJSユーザ・プロセスを必要とします。 アクティブなNETRJSユーザ・プロセスは「仮想の遠く離れたバッチ・ターミナル」、または"VRBT"をシミュレートします。
A VRBT may have virtual card readers, printers, and punches. In
addition, every VRBT has a virtual remote operator console. Using a
virtual card reader, a Network user can transmit a stream of card
images comprising one or more batch jobs, complete with job control
language ("JCL"), to the batch server host. The NETRJS server will
cause these jobs to be spooled into the batch system to be executed
according to their priority. NETRJS will automatically 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
was submitted. The batch user can wait for his output, or he can
signoff and signon again later to receive it.
VRBTには、仮想のカードリーダ、プリンタ、およびパンチがあるかもしれません。 さらに、あらゆるVRBTには、仮想のリモートオペレータコンソールがあります。 バーチャルカード読者を使用して、Networkユーザは1つ以上のバッチ・ジョブを包括するカードイメージのストリームを伝えることができます、ジョブ制御言語("JCL")で完全です、バッチサーバー・ホストに。 NETRJSサーバで、それらの優先権に従って実行されるためにこれらの仕事をバッチシステムにスプールするでしょう。 NETRJSは自動的に仮想のプリンタ、そして/または、カードパンチへのこれらの仕事で仕事が提出されたVRBTに作成される印刷、そして/または、パンチ出力イメージを返すでしょう。 バッチユーザが彼の出力を待つことができますか、または再びそれを受けるのが、より遅いsignoffとsignonを待つことができます。
To initiate a NETRJS session, the user process must execute a standard ICP to a fixed socket at the server. The result is to establish a full-duplex Telnet connection for the virtual remote operator console, allowing the VRBT to signon to RJS. The virtual remote operator console can then be used to issue commands to NETRJS and to receive status, confirmation, and error messages from the
NETRJSセッションを開始するために、ユーザ・プロセスはサーバで固定ソケットに標準のICPを実行しなければなりません。結果は仮想のリモートオペレータコンソールのための全二重Telnet接続を確立することです、RJSへのsignonにVRBTを許容して。 そして、NETRJSにコマンドを発行して、状態、確認、およびエラーメッセージを受け取ることに仮想のリモートオペレータコンソールを使用できます。
Braden [page 1]
ブレーデン[1ページ]
RFC 740 RTB 42423 22 Nov 77 NETRJS Protocol
RFC740RTB42423 1977年11月22日のNETRJSプロトコル
server. The most important remote operator commands are summarized in Appendix D.
サーバ最も重要なリモートオペレータコマンドはAppendix Dにまとめられます。
Different VRBT's are distinguished by 8-character terminal id's, which are assigned by the server site to individual batch users or user groups.
異なったVRBTのものはイドの8文字端末のものによって区別されます。(それは、サーバサイトによって個々のバッチユーザかユーザ・グループに配属されます)。
B. Connections and Protocols
B。 コネクションズとプロトコル
The protocol uses up to five connections between the user and server processes. The operator console uses a a full-duplex Telnet connection. The data transfer streams for the virtual card reader, printer, and punch each use a separate simplex connection under a data transfer protocol defined in Appendix A. This document will use the term "channel" for one of these simplex data transfer connections and will designate a connection "input" or "output" with reference to the server.
プロトコルはユーザとサーバプロセスとの最大5つの接続を使用します。 オペレータコンソールはa全二重Telnet接続を使用します。 データ転送は仮想のカードリーダ、プリンタ、およびパンチのためにAppendix A.Thisで定義されたデータ転送プロトコルの下における別々のシンプレクス接続がこれらのシンプレクスデータ転送コネクションのひとりに「チャンネル」という用語を使用して、サーバに関して接続「入力」か「出力」を指定すると記録する各使用を流します。
A particular data transfer channel needs to be open only while it is in use, and different channels may be used sequentially or simultaneously. CCN's NETRJS server will support 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. The NETRJS protocol could easily be extended to any number of simultaneously-operating virtual card readers, printers, and punches.
それは単に使用中ですが、特定のデータ転送チャンネルは、開く必要があります、そして、異なったチャンネルは連続するか同時に、使用されるかもしれません。 CCNのNETRJSサーバは同じVRBTプロセスの上で仮想のカードリーダ、仮想のプリンタ、および仮想のパンチ(オペレータコンソールに加えた)の同時処理操作をサポートするでしょう。 容易にいろいろな同時に稼働している仮想のカードリーダ、プリンタ、およびパンチにNETRJSプロトコルを広げることができました。
The NETRJS server takes a passive role in opening the data channels: the server only "listens" for an RFC from the user process. NETRJS is defined with an 8-bit byte size on all data channels.
NETRJSサーバはデータ・チャンネルを開けることにおける受け身の役割を果たします: サーバはRFCのためにユーザ・プロセスから「聴かれるだけです」。 NETRJSはすべてのデータのサイズが向ける8ビットのバイトで定義されます。
Some implementations of NETRJS user processes are daemons, operating as background processes to submit jobs from a list of user requests; other implementations are interactive processes executed directly under terminal control by remote users. In the latter case, the VRBT process generally multiplexes the user terminal between NETRJS, i.e., acting as the remote operator console, and entering local commands to control the VRBT. Local VRBT commands allow selection of the files containing job streams to be sent to the server as well as files to receive job output from the server. Other local commands would cause the VRBT to open data transfer channels to the NETRJS server and to close these channels to free buffer space or abort transmission.
NETRJSユーザ・プロセスのいくつかの実装がデーモンです、バックグラウンドがユーザ要求のリストから仕事を提出するために処理されながら作動して。 他の実装は端末のコントロールの直接下でリモート・ユーザーによって実行された対話的なプロセスです。 一般に、後者の場合では、すなわち、VRBTプロセスは、リモートオペレータコンソールとして機能して、VRBTを制御するローカルのコマンドを入力しながら、NETRJSの間のユーザ端末を多重送信します。 ローカルのVRBTコマンドは、ジョブストリームを含むファイルの品揃えがサーバに送られるのを許容して、ファイルがサーバから仕事の出力を受け取るのを許容します。他のローカルのコマンドは、VRBTがNETRJSサーバにデータ転送チャンネルを開けて、バッファ領域を解放するか、またはトランスミッションを中止するためにこれらのチャンネルを閉じることを引き起こすでしょう。
The user process has a choice of three ICP sockets, to select the character set of the VRBT -- ASCII-68, ASCII-63, or EBCDIC. The server will make the corresponding translation of the data in the card reader and printer channels. (In the CCN implementation of NETRJS, an EBCDIC VRBT will transmit and receive, without
ユーザ・プロセスに、VRBTの文字集合を選択するために、3個のICPソケットの選択があります--ASCII-68、ASCII-63、またはEBCDIC。 サーバはカードリーダとプリンタチャンネルによるデータの対応する翻訳をするでしょう。 (NETRJSのCCN実装では、EBCDIC VRBTは送受信するでしょう。
Braden [page 2]
ブレーデン[2ページ]
RFC 740 RTB 42423 22 Nov 77 NETRJS Protocol
RFC740RTB42423 1977年11月22日のNETRJSプロトコル
translation, "transparent" streams of 8-bit bytes, since CCN is an EBCDIC installation). The punch stream will always be transparent, outputting "binary decks" of 80-byte records untranslated. The operator console connections always use Network ASCII, as defined by the Telnet protocol.
翻訳、CCN以来の8ビットのバイトの「透明な」ストリームがEBCDICインストールである、) 非翻訳された80バイトの記録の「2進のデッキ」を出力して、パンチストリームはいつもわかりやすくなるでしょう。 オペレータコンソール接続はTelnetプロトコルによって定義されるようにいつもNetwork ASCIIを使用します。
The NETRJS protocol provides data compression, replacing repeated blanks or other characters by repeat counts. However, when the terminal id is assigned, a particular network VRBT may be specified to use 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" (see Appendix A).
繰り返された空白か他のキャラクタを繰返し回数に取り替えて、NETRJSプロトコルはデータ圧縮を提供します。 しかしながら、端末のイドが割り当てられるとき、特定のネットワークVRBTは、データ圧縮を全く使用しないように指定されるかもしれません。 この場合、NETRJSは「端が欠けている形式」と呼ばれる簡単な「オペコード長さのデータ」フォームで、引きずっている空白に単に先端を切らせて、記録を送るでしょう(Appendix Aを見てください)。
C. Starting and Terminating a Session
C。 始まって、セッションを終えます。
The remote user establishes a connection to the NETRJS server by executing an ICP to the contact socket 71 (decimal) for EBCDIC, socket 73 (decimal) for ASCII-68, or to socket 75 (decimal) for ASCII-63. A successful ICP results in a pair of connections which are in fact the NETRJS operator console connections. NETRJS will send a READY message over the operator output connection.
リモート・ユーザーは、EBCDICのための接触ソケット71(小数)、ASCII-68のためのソケット73(小数)、または、ASCII-63のためのソケット75(小数)にICPを実行することによって、NETRJSサーバに取引関係を築きます。 うまくいっているICPは事実上NETRJSオペレータコンソール接続である接続の1組をもたらします。 NETRJSはオペレータ出力接続の上にREADYメッセージを送るでしょう。
The user (process) must now enter a valid NETRJS signon command
("SIGNON terminal-id") through the virtual remote operator console.
RJS will normally acknowledge signon with a console message; however,
if there is no available NETRJS server port, NETRJS will indicate
refusal by closing both operator connections. If the user fails to
enter a valid signon within 3 minutes, NETRJS will close the operator
connections. If the VRBT attempts to open data transfer channels
before the signon command is accepted, the data transfer channels
will be refused with an error message to the VRBT operator console.
ユーザ(プロセス)は今、仮想のリモートオペレータコンソールを通した有効なNETRJS signonコマンド(「SIGNONの端末のイド」)を入力しなければなりません。 通常、RJSはコンソールメッセージがあるsignonを承認するでしょう。 しかしながら、どんな利用可能なNETRJSサーバポートもないと、NETRJSは、両方のオペレータ接続を終えることによって、拒否を示すでしょう。 ユーザが3分以内に有効なsignonに入らないと、NETRJSはオペレータ接続を終えるでしょう。 VRBTが、signonコマンドを受け入れる前にデータ転送チャンネルを開けるのを試みると、データ転送チャンネルはエラーメッセージでVRBTオペレータコンソールに拒否されるでしょう。
Suppose that S is the even number sent in the ICP; then the NETRJS connections have sockets at the server with fixed relation to S, as shown in the following table:
SがICPで送られた偶数であると仮定してください。 次に、NETRJS接続はSとの固定関係と共に以下のテーブルに示されるようにサーバでソケットを持っています:
Channel Server Socket User Socket ------- ------------- ----------- Remote Operator Console Input S U + 3 Telnet Remote Operator Console Output S + 1 U + 2 Telnet Data Transfer - Card Reader #1 S + 2 any odd number Data Transfer - Printer #1 S + 3 any even number Data Transfer - Punch #1 S + 5 any even number
チャンネルサーバソケットユーザソケット------- ------------- ----------- リモートOperator Console Input S U+3Telnet Remote Operator Console Output S+1U+2Telnet Data Transfer--カード読者#1秒間+2つ、プリンタ#1秒間+3の間、いずれもData Transferに付番さえするというどんな奇数Data Transferも#1秒間+5の間、どんな偶数もパンチします。
Once the VRBT has issued a valid signon, it can open data transfer channels and initiate input and output operations as explained in the following sections. To terminate the session, the VRBT may close all
VRBTがいったん有効なsignonを発行すると、それは、以下のセクションで説明されるようにデータ転送チャンネルを開けて、入出力操作を開始できます。 セッションを終えるために、VRBTはすべてを閉じるかもしれません。
Braden [page 3]
ブレーデン[3ページ]
RFC 740 RTB 42423 22 Nov 77 NETRJS Protocol
RFC740RTB42423 1977年11月22日のNETRJSプロトコル
connections. Alternatively, it may enter a SIGNOFF command through the virtual remote operator console. Receiving a SIGNOFF, NETRJS will wait until the current job output streams are complete and then itself terminate the session by closing all connections.
接続。 あるいはまた、それは仮想のリモートオペレータコンソールを通したSIGNOFFコマンドを入力するかもしれません。 SIGNOFFを受けて、現在のジョブ出力ストリームが終了していて、その時自体がすべての接続を終えることによってセッションを終えるまで、NETRJSは待つでしょう。
D. Input Operations
D。 入力操作
A job stream for submission to the NETRJS server is a series of logical records, each of which is a card image of at most 80 characters. The user can submit a "stack" of successive jobs through the card reader channel with no end-of-job indication between jobs; NETRJS is able to parse the JCL sufficiently to recognize the beginning of each job.
NETRJSサーバへの服従のためのジョブストリームは一連の論理レコードです。それのそれぞれが高々80のキャラクタのカードイメージです。 ユーザは仕事の間のエンド・オブ・ジョブの指示なしでカードリーダチャンネルによる連続した仕事の「スタック」を提出できます。 NETRJSはJCLをそれぞれの仕事の始まりを認識できるくらい分析できます。
To submit a batch job or stack of jobs for execution, the user process must first open the card reader channel by issuing an Init for foreign socket S+2 and the appropriate local socket. NETRJS, which is listening on socket S+2, will return an RTS command to open the channel. When the channel is open, the user can begin sending his job stream using the protocol defined in Apendix A. For each job successfully spooled, NETRJS will send a confirming message to the remote operator console.
実行のための仕事のバッチ・ジョブかスタックを提出するために、ユーザ・プロセスは最初に、外国ソケットS+2と適切な地方のソケットのためにInitを発行することによって、カードリーダチャンネルを開けなければなりません。 NETRJS(ソケットS+2で聴いている)はチャンネルを開けるRTSコマンドを返すでしょう。 チャンネルがオープンであるときに、ユーザは、Apendix A.Forでの首尾よくスプールされた各仕事をプロトコルが定義した彼のジョブストリーム使用に送り始めることができて、NETRJSはリモートオペレータコンソールに確認メッセージを送るでしょう。
At the end of the job stack, the user process must send an End-of-Data transaction 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 process can re-open the card reader channel and transmit another job stack. It can also terminate the session and signon later to get the output.
ジョブスタックの端に、ユーザ・プロセスは、最後の仕事の処理を開始するためにデータのEndトランザクションを送らなければなりません。 そして、NETRJSはチャンネル(不必要にバッファ領域を保持するのを避ける)を閉じるでしょう。 いつでも、セッションの間、ユーザ・プロセスは、カードリーダチャンネルを再開させて、別のジョブスタックを伝えることができます。 また、それは、後で出力を手に入れるためにセッションとsignonを終えることができます。
If the user process leaves the channel open for 5 minutes without sending any bits, the server will abort (close) the channel. The user process can abort the card reader channel at any time by closing the channel; NETRJS will then discard the last partially 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 channel prematurely, and also inform the user process that the job was discarded (thus solving the race condition between End-of-Data and aborting). The user process should retransmit only those jobs in the stack that have not been completely spooled.
ユーザ・プロセスが5分間どんなビット発信しないでも開いた状態でチャンネルを残すと、サーバは(近いところで)チャンネルを堕胎するでしょう。 ユーザ・プロセスはいつでも、チャンネルを閉じることによって、カードリーダチャンネルを堕胎できます。 そして、NETRJSは最後に部分的にスプールさせられた仕事を捨てるでしょう。 NETRJSが間違いを見つけると(例えば、トランザクション一連番号誤りか下げられたビット)、それは、早まってチャンネルを閉じることによってチャンネルを堕胎して、また、仕事が捨てられたことをユーザ・プロセスに知らせるでしょう(その結果、データのEndと中止の間の競合条件を解決します)。 ユーザ・プロセスはスタックでの完全にスプールされるというわけではなかったそれらの仕事だけを再送するべきです。
If the user's process, NCP, or host, or the Network itself fails during 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 the server.
ユーザのプロセス、NCP、ホスト、またはNetwork自身が入力の間、失敗すると、RJSは伝えられる仕事を捨てるでしょう。 この仕事が捨てられたことをユーザに知らせるのを、彼が雇われる次の時に彼に生成して、送るというメッセージ。 他方では、領収書がオペレーターズコンソールの上で受け取ったことを知らせられたそれらの仕事は、失敗で影響を受けませんが、サーバによって実行されるでしょう。
Braden [page 4]
ブレーデン[4ページ]
RFC 740 RTB 42423 22 Nov 77 NETRJS Protocol
RFC740RTB42423 1977年11月22日のNETRJSプロトコル
E. Output Operations
E。 出力操作
The VRBT may wait to set up a virtual printer or punch and open its channel until a STATUS message from NETRJS indicates output is ready; or it may leave the output channel(s) open during the entire session, ready to receive output whenever it becomes available. The VRBT can also control which one of several available jobs is to be returned by entering appropriate operator commands.
VRBTは仮想のプリンタかパンチをセットアップして、NETRJSからのSTATUSメッセージが、出力が準備ができているのを示すまでチャンネルを開けるのを待つかもしれません。 または、それは出力チャネルを全体のセッションの間、開いて、利用可能になるときはいつも、出力を受け取る準備ができているままにするかもしれません。 また、VRBTは、適切なオペレータコマンドを入力することによって返すためにいくつかの利用可能な仕事の1つがどれであるかを制御できます。
To be prepared to receive printer (or punch) output from its jobs, the VRBT issues an Init for foreign socket S+3 or S+5 for printer or punch output, respectively. NETRJS is listening on these sockets and should immediately return an STR. However, it is possible that because of a buffer shortage, NETRJS will refuse the connection by returning a CLS; in this case, try again later.
仕事からプリンタ(パンチする)出力を受け取るように準備されるには、VRBTはそれぞれ出力されたプリンタかパンチのための外国ソケットS+3かS+5のためにInitを発行します。 NETRJSはこれらのソケットの上に聴いていて、すぐに、STRを返すはずです。 しかしながら、バッファ枯渇のために、NETRJSがCLSを返すことによって接続を拒否するのは、可能です。 この場合、後でもう一度試みてください。
When NETRJS has job output for 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 after the first will be an ASA carriage control character (see Appendix C). A virtual printer in NETRJS has 254 columns, exclusive of carriage control; NETRJS 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に特定の仮想端末のための仕事の出力と対応する開いている出力チャネルがあるとき、最初の記録がそうするAppendix A.でプロトコルを使用する一連の論理レコードがコンマと次に、IDストリングがJOBカードからもしあれば支えたジョブ名(8つのキャラクタ)から成るとき、それは出力を送るでしょう。 プリンタストリームでは、1日後のそれぞれの記録の最初のコラムはASAキャリッジ制御文字になるでしょう(Appendix Cを見てください)。 NETRJSの仮想のプリンタには、改行制御を除いて254のコラムがあります。 NETRJSはそれがSYSOUTデータセットで見つける論理レコードの最大255のキャラクタを送るでしょう。 ユーザが何らかのよりわずかなレコード・サイズより長い間記録を拒絶したいか、または折り重ねたいなら、彼はVRBTプロセスでそうすることができます。
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 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.
NETRJSはデータのEndトランザクションを送って、次に、それぞれの完全なバッチ・ジョブのための出力の端に出力チャネルを閉じるでしょう。 そして、リモートサイトは、別口の仕事のための出力を始動するために新しいRFCを送らなければなりません。 これは仕事の中で出力を壊さないで各仕事のための新しいファイルを割り当てる機会をリモートサイトに与えます。
If the batch user wants to cancel (or backspace or defer) the output of a particular job, he can enter appropriate NETRJS commands on the operator input channel (see Appendix D).
バッチユーザが取り消したがっている、(バックスペースキーを押して印字位置を一字分戻ってください、延期、)、特定の仕事の出力、彼はオペレータ入力チャンネルで適切なNETRJSコマンドを入力できます(Appendix Dを見てください)。
If NETRJS 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. If the user process stops accepting bits for 5 minutes, the server will abort the channel. In any case, the user will receive notification of termination of output data transfer for each job via a remote console message.
NETRJSがディスクデータセットを読む際に永久的な入出力エラーに遭遇すると、それは、彼のコンソールを通してユーザに通知して、前方に同じ仕事におけるシステムメッセージかSYSOUTデータセットの次のセットまでスキップして、続くでしょう。 ユーザ・プロセスが5分間受諾ビットを止めると、サーバはチャンネルを堕胎するでしょう。 どのような場合でも、ユーザはリモートコンソールメッセージで各仕事のための出力データ転送の終了の通知を受け取るでしょう。
Braden [page 5]
ブレーデン[5ページ]
RFC 740 RTB 42423 22 Nov 77 NETRJS Protocol
RFC740RTB42423 1977年11月22日のNETRJSプロトコル
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 the 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, NETRJS will simulate a Backspace command, 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 reopens the channnel in a later session; RJS saves the state of every incomplete output stream. 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 NETRJS has not yet sent the End-of-Data transaction.
ユーザがストリームにおける誤りを検出するなら、出力の最後の「ページ」、最後のSYSOUTデータセットから繰り返すRestart(RST)コマンドまたは仕事の始まりを繰り返すために彼のコンソールからBackspace(BSP)にコマンドを発行できますか、または彼は、彼のソケットを閉じることによって、チャンネルを堕胎できます。 彼がチャンネルを堕胎すると、NETRJSはBackspaceコマンドをシミュレートするでしょう、そして、ユーザがチャンネルを再開させると、仕事は再び同じデータセットで以前のポイントからトランスミッションを始めるでしょう。 ユーザが最初に、現在のセッションを終える、後のセッションのときにchannnelを再開させても、これは本当です。 RJSはあらゆる不完全な出力ストリームの事情を節約します。 しかしながら、チャンネルを再開させる前に、彼は、後の出力のためにこの仕事を延期するか、始めにそれを再開するか、または出力を中止できます(Appendix Dを見てください)。 NETRJSがまだデータのEndトランザクションを送らない場合にだけチャンネルを堕胎するのが有効であることに注意してください。
If the user's process, NCP, or host or the Network itself fails during an output operation, NETRJS will act as if the channel had been aborted and the user signed off. NETRJS will discard the output of a job only after receiving the RFNM from the last data transfer message (containing an End-of-Data). In no case should a NETRJS user lose output from a batch job.
ユーザの過程、NCP、ホストまたはNetwork自身が出力操作の間、失敗すると、まるでチャンネルが堕胎されて、ユーザがサインオフするかのようにNETRJSは行動するでしょう。 最後のデータ転送メッセージからRFNMを受けた後にだけ、NETRJSは仕事の出力を捨てるでしょう(データのEndを含んでいて)。 NETRJSユーザはバッチ・ジョブから出力を決して、なくすべきではありません。
Braden [page 6]
ブレーデン[6ページ]
RFC 740 RTB 42423 22 Nov 77 NETRJS Protocol
RFC740RTB42423 1977年11月22日のNETRJSプロトコル
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 preceded 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 server software,
and is limited to 880 8-bit 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.
取引は、サーバソフトウェアの中のバッファリングのユニットであり、8ビットの880バイトに制限されます。 取引は1つの記録と同じくらい短いことができます。 しかしながら、効率に関するそれらのサイトはできるだけ880バイトの限界の近くに取引を送るべきです。
There is no necessary connection between physical message
boundaries and transactions ("logical messages"); the NCP can
break a transaction arbitrarily into physical messages. The CCN
server starts each transaction at the beginning of a new physical
message, but this is not a requirement of the protocol.
物理メッセージ限界と取引(「論理メッセージ」)とのどんな必要な関係もありません。 NCPは任意に取引を物理メッセージに始めることができます。 CCNサーバは新しい物理メッセージの始めに各取引を始めますが、これはプロトコルの要件ではありません。
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 the receiver with a convenient way to verify
bit-synchronization, and it 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) the "op code" byte to verify bit
synchronization and (2) the transaction sequence number. Under the
NETRJS protocol, a data transfer error must abort the entire
transmission; there is no provision for restart.
(1) (2) 現在のNETRJSでの伝送エラー検出が議定書を作るので、唯一の条項が、ビット同期について確かめる「オペコード」バイトと取引一連番号です。 NETRJSプロトコルの下では、データ転送誤りは全体のトランスミッションを中止しなければなりません。 再開への支給が全くありません。
Braden [page 7]
ブレーデン[7ページ]
RFC 740 RTB 42423 22 Nov 77 NETRJS Protocol
RFC740RTB42423 1977年11月22日のNETRJSプロトコル
2. Meta-Notation
2. メタ記法
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 notation consists of a series of
productions for bit string variables. 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, '255'(8) and X'FF' both represent a string of 8 one bits.
NETRJSデータ転送プロトコルの以下の記述はRFC31でBobrowとサザーランドによって提案されたそれから得られた正式な記法を使用します。 記法はビット列変数のための一連の創作から成ります。 ビットの長さは固定長電界を表す各変数名のあとに続いています。(例えば、SEQNUMB(16))。 主なX意味十六進法によって資格がない場合、引用文に同封された数は10進です。 それぞれの十六進法ケタが4ビットであるので、長さは十六進法番号で明らかに示されません。 例えば、'255'の(8)とX'FF'はともに一連の8を1ビット表します。
The meta-syntactic operators are:
メタ構文のオペレータは以下の通りです。
| :alternative string
| :alternativeストリング
[ ] :optional string
[ ]:optionalストリング
( ) :grouping
( ) :grouping
+ :catenation of bit strings
+ ビット列の: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の数値を象徴します。
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
greater or equal to 0 is assumed unless n is explicitly
restricted.
最終的に、私たちはサブストリングの繰り返しにBobrowとサザーランドのシンボリズムを使用します: (STRING-EXPRESSION=n)。 それとなく一緒にcatenatedされたSTRING-EXPRESSIONのn発生を指示します。 ここで、nが明らかに制限されない場合、0と、より優れたか等しいどんなnも想定されます。
3. Protocol Definition
3. プロトコル定義
STREAM ::= (TRANSACTION = n) + [END-OF-DATA]
以下を流してください:= (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)
取引:、:= THEAD(72)+(RECORDはrと等しいです)+('0'(1)=f)
That is, a transaction consists of a 72 bit header, r records,
and f filler bits; it may not exceed 880*8 bits.
すなわち、取引は72ビットのヘッダー、r記録、およびfフィラービットから成ります。 それは880*8ビットを超えないかもしれません。
Braden [page 8]
ブレーデン[8ページ]
RFC 740 RTB 42423 22 Nov 77 NETRJS Protocol
RFC740RTB42423 1977年11月22日のNETRJSプロトコル
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 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 for each terminal id.
RJSは入力ストリームでCOMPRESSEDかTRUNCATEDである混ぜられたRECORDのものを受け入れるでしょう。 RJSはプリンタとパンチストリームで1かもう片方の形式を与えられたVRBTに送るでしょう。 選択はそれぞれの端末のイドのために決定します。
COMPRESSED ::= '2'(2) + DEVID(6) + (STRING = p) + '0'(8)
圧縮される:、:= '2'(2)+DEVID(6)+(STRINGはpと等しい)+'0'(8)
STRING ::= ('6'(3) + i:DUPCOUNT(5)) |
以下を結んでください:= ('6'(3)+i: DUPCOUNT(5)) |
This form represents a string of i consecutive blanks
このフォームは一連のi連続した空白を表します。
('7'(3) + i:DUPCOUNT(5) + TEXTBYTE(8)) |
(+ i: '7'(3)DUPCOUNT(5)+TEXTBYTE(8))|
This form represents string of i consecutive duplicates of
TEXTBYTE.
このフォームはTEXTBYTEのi連続した写しのストリングを表します。
('2'(2) + j:LENGTH(6) + (TEXTBYTE(8) = j))
('2'(2)+j: LENGTH(6)+(TEXTBYTE(8)はjと等しいです))
This form represents a string of j characters.
このフォームは一連のjキャラクタの代理をします。
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への出力: 未使用
Braden [page 9]
ブレーデン[9ページ]
RFC 740 RTB 42423 22 Nov 77 NETRJS Protocol
RFC740RTB42423 1977年11月22日のNETRJSプロトコル
DEVNO identifies the particular device of type t at this remote
site; at present only DEVNO = 0 is possible.
DEVNOはこのリモートサイトでタイプtの特定の装置を特定します。 現在のところ、DEVNOだけ=0は可能です。
END-OF-DATA ::=X'FE'
データの終わり:、:=X'FE'
Signals end of job (output) or job stack (input).
信号エンド・オブ・ジョブ(出力)かジョブスタック(入力)。
Braden [page 10]
ブレーデン[10ページ]
RFC 740 RTB 42423 22 Nov 77 NETRJS Protocol
RFC740RTB42423 1977年11月22日のNETRJSプロトコル
APPENDIX B
付録B
Telnet for VRBT Operator Console
VRBTオペレータコンソールのためのtelnet
The remote operator console connections use the ASCII Telnet protocol. Specifically:
リモートオペレータコンソール接続は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
----------------------------------------------------
broken vertical bar | solid vertical bar
tilde | not sign
back slash | cent sign
telnetにおけるASCII| NETRJS---------------------------------------------------- 壊れている縦棒| しっかりした縦棒ティルド| サインの逆スラッシュでない| セント記号
2. Telnet controls are ignored.
2. telnetコントロールは無視されます。
3. An operator console input line which exceeds 133 characters
(exclusive of CR LF) is truncated by NETRJS.
3. 133のキャラクタ(CR LFを除いた)を超えているオペレータコンソール入力行はNETRJSによって先端を切られます。
4. NETRJS accepts BS (Control-H) to delete a character and CAN
(Control-X) to delete the current line. The sequence CR LF
terminates each input and output line. HT (Control-I) is
translated to a single space. An ETX (Control-C) terminates
(aborts) the session. All other ASCII control characters are
ignored.
4. NETRJSは、現在行を削除するために、キャラクタとCAN(コントロールX)を削除するために、BS(コントロールH)を受け入れます。 系列CR LFはそれぞれの入出力線を終えます。 HT(私を監督している)はシングルスペースに翻訳されます。 ETX(コントロールC)はセッションを終えます(中止になります)。 他のすべてのASCII制御文字が無視されます。
5. NETRJS translates the six ASCII graphics with no equivalent in
EBCDIC into the character question mark ("?") on input.
5. NETRJSは入力のときにEBCDICで同等物なしでキャラクタ疑問符(“?")に6つのASCIIグラフィックスを翻訳します。
Braden [page 11]
ブレーデン[11ページ]
RFC 740 RTB 42423 22 Nov 77 NETRJS Protocol
RFC740RTB42423 1977年11月22日のNETRJSプロトコル
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 12]
ブレーデン[12ページ]
RFC 740 RTB 42423 22 Nov 77 NETRJS Protocol
RFC740RTB42423 1977年11月22日のNETRJSプロトコル
APPENDIX D
付録D
Network/RJS Command Summary
ネットワーク/RJSコマンド概要
This section presents an overview of the RJS Operator Commands, for the complete form and parameter specifications please see references 2 and 3.
このセクションはRJS Operator Commandsの概観を提示します、仕様が喜ばせる完全なフォームとパラメタが参照2と3を見るので。
Terminal Control and Information Commands
端末のコントロールと情報コマンド
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 batch host.
リモートオペレータコンソールa全リストの上のSTATUS Outputs、またはこのVRBTのシステムにおけるそれらの処理状態のしるしがバッチホストにあるすべての仕事の概要。
ALERT Outputs on the remote operator console an "Alert"
message, if any, from the computer operator. The
Alert message is also automatically sent when the
user does a SIGNON, or whenever the message changes.
コンピュータオペレータからのもしあればリモートオペレータコンソール「警戒」メッセージのALERT Outputs。 また、ユーザがSIGNONをするか、またはメッセージが変化するときはいつも、自動的にAlertメッセージを送ります。
MSG Sends a message to the 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.
コンピュータオペレータ、または、いかなる他の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 destined 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
until 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 operator) before RJS will send it. The
Active/Deferred choice for output from a job is determined by the
RJS場所は、特定の遠隔端末のためにActive QueueかDeferred Queueのどちらかに運命づけられた出力を、印刷して、パンチします。 ユーザが彼の印刷かパンチ出力チャネルを開くとき、RJSはすぐにActive Queueから仕事の出力を送り始めて、この待ち行列が空になるまで、続きます。 他方では、ジョブ名でDeferred Queueでの仕事の出力を求めなければならない、(リモートオペレータからのRESETコマンドを通した) 以前、RJSはそれを送るでしょう。 仕事からの出力があるので、Active/延期された選択は自決しました。
Braden [page 13]
ブレーデン[13ページ]
RFC 740 RTB 42423 22 Nov 77 NETRJS Protocol
RFC740RTB42423 1977年11月22日のNETRJSプロトコル
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.
仕事であるときに、VRBTの延期状態は入られます。 SETコマンドで延期状態(ユーザが雇われるときActiveオプションに設定される)を変えるかもしれません。
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 Queueまでの仕事のために出力したDEFERムーヴス。 チャンネルの上に伝えられることの途中に仕事の出力があるなら、仕事をDeferred Queueに動かす前に、RJSはチャンネルを堕胎して、経常産出高位置を節約します。 その後の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 the
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 currently executing.
首尾よく提出していて、待ち実行であったか現在実行であるABORTキャンセルa仕事。
Output Stream Control Commands
出力ストリーム制御機能コマンド
BSP (BACKSPACE) "Backspaces" output stream within current sysout
data set. Actual amount backspaced depends upon
sysout blocking but is roughly 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 remaining
出力チャネルのCAN(キャンセル)(a)、CANは現在伝えられるsysoutデータセットにおける、出力の残りを省略させます。 あるいはまた、現在伝えられる仕事のためのsysoutデータセットの残りを省略するかもしれません。 しかしながら、残り
Braden [page 14]
ブレーデン[14ページ]
RFC 740 RTB 42423 22 Nov 77 NETRJS Protocol
RFC740RTB42423 1977年11月22日のNETRJSプロトコル
system and accounting messages will be sent.
システムと会計メッセージを送るでしょう。
(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
beginning of the current sysout data set or,
optionally, at the beginning of the job.
RST(RESTART)(a)は現在のsysoutデータセットの始めか任意に仕事の始めに指定された出力ストリームを再開します。
(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,
optionally, 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
and/or punch stream.
カードリーダストリームが支持するEAMエコーズはプリンタ、そして/または、パンチを流れます。
Braden [page 15]
ブレーデン[15ページ]
RFC 740 RTB 42423 22 Nov 77 NETRJS Protocol
RFC740RTB42423 1977年11月22日のNETRJSプロトコル
APPENDIX E
付録E
NETRJS TERMINAL OPTIONS
NETRJSの端末のオプション
When a new NETRJS virtual terminal is defined, certain options are available; these options are listed below.
新しいNETRJS仮想端末が定義されるとき、あるオプションは利用可能です。 これらのオプションは以下に記載されています。
1. Truncated/Compressed Data Format
1. 端が欠けているか圧縮されたデータの形式
A VRBT may use either the truncated data format (default) or
the compressed format for printer and punch output. See
Reference 9 for discussion of the virtues of compression.
VRBTはプリンタとパンチ出力に不完全なデータ形式(デフォルト)か圧縮形式のどちらかを使用するかもしれません。 圧縮の美徳の議論に関してReference9を見てください。
2. Automatic Coldstart Job Resubmission
2. 自動コールドスタート仕事のResubmission
If "R" (Restart) is specified in the accounting field on the
JOB card and if this option is chosen, RJS will automatically
resubmit the job from the beginning if the server operating
system should be "coldstarted" before all output from the job
is returned. Otherwise, the job will be lost and must be
resubmitted from the remote terminal in case of a coldstart.
「R」(再開)が仕事のカードの会計分野で指定されて、このオプションが選ばれていると、仕事からのすべての出力が返される前にサーバオペレーティングシステムが"coldstartedする"であるなら、RJSは始めから仕事を自動的に再提出するでしょう。 さもなければ、仕事を失われて、コールドスタートの場合に遠隔端末から再提出しなければなりません。
3. Automatic Output RESTART
3. 自動出力再開
With this option, transmission of printer output which is
interrupted by a broken connection always starts over at the
beginning. Without this option, the output is backspaced
approximately one page when restarted, unless the user forces
the output to start over from the beginning with a RESTART
command when the printer channel is re-opened and before
printing begins.
このオプションで、失意の接続によって中断されるプリンタ出力の送信は始めにいつもやり直されます。 再開されると、出力はこのオプションがなければバックスペースキーを押して印字位置を一字分戻ったおよそ1ページです、RESTARTコマンドがあるプリンタチャンネルが再開する始め、印刷が始まる前にユーザが出力を強制的にやり直させない場合。
4. Password Protection
4. パスワード保護
This option allows a password to be supplied when a terminal is
signed on, preventing unauthorized use of the terminal ID.
端末上がサインされるとき、このオプションは、パスワードが提供されるのを許容します、端末のIDの無断使用を防いで。
5. Suppression of Punch Separator and Large Letters.
5. パンチ分離符と大きい手紙の秘匿。
This option suppresses both separator cards which RJS normally
puts in front of each punched output deck, and separator pages
on printed output containing the job name in large block
letters. These separators are an operational aid when the
ouptut is directed to a real printer or punch, but generally
undesirable for an ARPA user who is saving the output in a file
for on-line examination.
このオプションは大きいゴシック体にジョブ名を含むプリント出力のときに通常、RJSがそれぞれのパンチされた出力デッキの正面に置く分離符カードと分離符ページの両方を抑圧します。 ouptutが本当のプリンタかパンチに向けられますが、オンライン試験のためのファイルにおける出力を取っておいているARPAユーザには、一般に望ましくないときに、これらの分離符は操作上の援助です。
Braden [page 16]
ブレーデン[16ページ]
RFC 740 RTB 42423 22 Nov 77 NETRJS Protocol
RFC740RTB42423 1977年11月22日のNETRJSプロトコル
APPENDIX F
付録F
Character Translation by CCN Server
CCNサーバによる文字変換
A VRBT declares its character set for job input and output by the initial connection socket it chooses. A VRBT can have the ASCII-68, the ASCII-63, or the EBCDIC character set. The ASCII-63 character mapping was added to NETRJS at the request of users whose terminals are equipped with keyboards like those found on the model 33 Teletype.
VRBTは仕事の入出力のためにそれが選ぶ初期の接続ソケットで文字集合を宣言します。 VRBTはASCII-68、ASCII-63、またはEBCDlC文字にセットさせることができます。 ASCII-63キャラクタマッピングはものがモデルの上で33テレタイプを見つけたように端末がキーボードを備えているユーザの依頼でNETRJSに加えられました。
Since CCN operates an EBCDIC machine, its NETRJS server translates ASCII input to EBCDIC and translates printer output back to ASCII. The details of this translation are described in the following.
CCNがEBCDICマシンを操作するので、NETRJSサーバは、EBCDICに入力されたASCIIを翻訳して、プリンタ出力をASCIIに翻訳して戻します。 この翻訳の詳細は以下で説明されます。
For ASCII-68, the following rules are used:
ASCII-68において、以下の規則は使用されています:
1. There is one-to-one mapping between the three ASCII characters
broken vertical bar, tilde, and back slash, which are not in
EBCDIC, and the three EBCDIC characters vertical bar, not
sign, and cent sign (respectively), which are not in ASCII.
1. ASCIIにはない壊れている縦棒、ティルド、および後部がなでぎりする3人のASCII文字と、どれが署名するのではなく、EBCDIC、および3EBCDICキャラクタ縦棒にないか、そして、セント記号(それぞれ)の間には、1〜1つのマッピングがあります。
2. The other six ASCII graphics not in EBCDIC are translated on
input to unused EBCDIC codes, shown in the table below.
2. 他の6つのASCIIグラフィックスは入力のときにEBCDICで以下のテーブルに示された未使用のEBCDICコードに翻訳されません。
3. The ASCII control DC4 is mapped to and from the EBCDIC control
TM.
3. ASCIIコントロールDC4はTMとEBCDICコントロールTMから写像されます。
4. The other EBCDIC characters not in ASCII are mapped in the
printer stream into the ASCII question mark.
4. 他のEBCDlC文字はプリンタストリームでASCII疑問符にASCIIで写像されません。
For ASCII-63, the same rules are used except that the ASCII-63 codes X'60' and X'7B' - X'7E' are mapped as in the following table.
'ASCII-63において、ASCII-63がX60年'X'7Bをコード化するのを除いて、同じ規則は使用されています'--X'7E'は以下のテーブルのように写像されます。
EBCDIC | ASCII-68 VRBT | ASCII-63 VRBT
---------------------------------------------------------------
vertical bar X'4F' | vertical bar X'7C' | open bracket X'5B'
not sign X'5F' | tilde X'7E' | close bracket X'5D'
cent sign X'4A' | back slash X'5C' | back slash X'5C'
underscore X'6D' | underscore X'5F' | left arrow X'5F'
. X'71' | up arrow X'5E' | up arrow X'5E'
open bracket X'AD' | open bracket X'5B' | . X'7C'
close bracket X'BD' | close bracket X'5D' | . X'7E'
. X'8B' | open brace X'7B' | . X'7B'
. X'9B' | close brace X'7D' | . X'7D'
. X'79' | accent X'60' | . X'60'
EBCDIC| ASCII-68VRBT| ASCII-63VRBT--------------------------------------------------------------- 垂直なバーX'4F'| 垂直なバーX'7C'| '開きの角括弧サインではなく、X'5B'X'5F'| '7E'というティルドX| '近いブラケットX'5D'セント記号X'4A'| 逆スラッシュX'5C'| 'X'5C'強調X'6Dはなでぎりし返します'| '5F'Xの下線を引いてください。| '左向きの矢X'5F'X71年'| 矢X'5のE'に| 矢Xの'5E'の開きの角括弧X'AD'に| '開きの角括弧X'5B'| . '7C'のX近いブラケットX'BD'| '近いブラケットX'5D'| . 'X'7E'X'8B'| '開きの中括弧X'7B'| . 'X'7B'X'9B'| '近い支柱X'7D'| . 'X'7D'X79年'| 'X60年にアクセントをつけてください'| . 'X60年'
Braden [page 17]
ブレーデン[17ページ]
RFC 740 RTB 42423 22 Nov 77 NETRJS Protocol
RFC740RTB42423 1977年11月22日のNETRJSプロトコル
APPENDIX G
付録G
REFERENCES
参照
1. "Interim NETRJS Specifications", R. T. Braden. RFC #189: NIC #7133, July 15, 1971.
1. 「当座のNETRJS仕様」、R.T.ブレーデン。 RFC#189: NIC#7133年7月15日、1971。
This was the basic system programmer's definition document. The
proposed changes mentioned on the first page of RFC #189 were
never implemented, since the DTP then in vogue became obsolete.
これは基本体系プログラマの定義ドキュメントでした。 189が決して実装されなかったRFC#の最初のページで言及されて、次に、DTP以来流行している変更案は時代遅れになりました。
2. "NETRJS Remote Operator Commands", R. T. Braden. NIC #7182, August 9, 1971
2. 「NETRJSのリモートオペレータコマンド」、R.T.ブレーデン。 NIC#7182年8月9日、1971
This document together with References 3 and 8 define the remote
operator (i.e. user) command language for NETRJS, and form the
basic user documentation for NETRJS at CCN.
References3と8に伴うこのドキュメントは、NETRJSのためにリモートオペレータ(すなわち、ユーザ)コマンド言語を定義して、NETRJSのために基本的なユーザドキュメンテーションをCCNに形成します。
3. "Implementation of a Remote Job Service", V. Martin and T. W. Springer. NIC #7183, July, 1971.
3. 「リモート・ジョブサービスの実装」、V.マーチン、およびT.W.追出石。 1971年7月のNIC#7183。
4. "Remote Job Entry to CCN via UCLA Sigma 7; A scenario", UCLA/CCN. NIC #7748, November 15, 1971.
4. 「UCLA Sigma7を通したCCNへのリモートJob Entry」。 「シナリオ」、UCLA/CCN。 NIC#7748年11月15日、1971。
This document described the first NETRJS user implementation
available on a server host. This program is no longer of general
interest.
このドキュメントはサーバー・ホストで利用可能な最初のNETRJSユーザ実装について説明しました。 このプログラムはもうどんな一般的興味のものではありません。
5. "Using Network Remote Job Entry", E. F. Harslem. RFC #307: NIC #9258, February 24, 1972.
5. 「ネットワークリモートジョブエントリを使用します」、E.F.Harslem。 RFC#307: NIC#9258年2月24日、1972。
This document is out of date, but describes generally the Tenex
NETRJS user process "RJS".
このドキュメントは、時代遅れですが、一般にTenex NETRJSユーザ・プロセス「RJS」について説明します。
6. "EBCDIC/ASCII Mapping for Network RJS", R. T. Braden. RFC #338: NIC #9931, May 17, 1972.
6. 「ネットワークのためにRJSを写像するEBCDIC/ASCII」、R.T.ブレーデン。 RFC#338: NIC#9931年5月17日、1972。
The ASCII-63 mapping described here is no longer correct, but
CCN's standard ASCII-68/EBCDIC mapping is described correctly.
This information is accurately described in Appendix F of the
current document.
ここで説明されたASCII-63マッピングはもう正しくはありませんが、CCNの標準のASCII-68/EBCDICマッピングは正しく説明されます。 この情報は現在のドキュメントのAppendix Fで正確に説明されます。
Braden [page 18]
ブレーデン[18ページ]
RFC 740 RTB 42423 22 Nov 77 NETRJS Protocol
RFC740RTB42423 1977年11月22日のNETRJSプロトコル
7. "NETRJT--Remote Job Service Protocol for TIP's", R. T. Braden. RFC #283: NIC 38165, December 20, 1971.
7. 「NETRJT--リモート賃仕事のサービスはティップのもののために議定書を作る」、R.T.ブレーデン。 RFC#283: 1971年12月20日のNIC38165。
This was an attempt to define an rje protocol to handle TIPs.
Although NETRJT was never implemented, many of its features are
incorporated in the current Network standard RJE protocol.
これはTIPsを扱うためにrjeプロトコルを定義する試みでした。 NETRJTは決して実装されませんでしたが、特徴の多くが現在のNetwork標準のRJEプロトコルで組み込んでいます。
8. "CCN NETRJS Server Messages to Remote User", R. T. Braden. NIC #20268, November 26, 1973.
8. 「リモート・ユーザーへのCCN NETRJSサーバメッセージ」、R.T.ブレーデン。 1973年11月26日のNIC#20268。
9. "FTP Data Compression", R. T. Braden. RFC #468: NIC #14742, March 8, 1973.
9. 「FTPデータ圧縮」、R.T.ブレーデン。 RFC#468: 1973年3月8日のNIC#14742。
10. "Update on NETRJS", R. T. Braden. RFC #599: NIC #20854, December 13, 1973.
10. 「NETRJSに関する最新情報」、R.T.ブレーデン。 RFC#599: 1973年12月13日のNIC#20854。
This updated reference 1, the current document combines the two.
これは参照1をアップデートして、現在のドキュメントコンバインは2です。
11. "Network Remote Job Entry -- NETRJS", G. Hicks. RFC #325: NIC 9632, April 6, 1972.
11. 「リモートジョブエントリをネットワークでつないでください--NETRJS」、G.ヒックス。 RFC#325: NIC、9632年4月6日、1972
12. "CCNRJS: Remote Job Entry between Tenex and UCLA-CCN", D. Crocker. NUTS Note 22, [ISI]<DOCUMENTATION>CCNRJS.DOC, March 5, 1975.
12. 「CCNRJS:」 「TenexとUCLA-CCNの間のリモートジョブエントリ」、D.クロッカー。 ナットは1975年3月5日に22、[ISI]<ドキュメンテーション>CCNRJS.DOCに注意します。
13. "Remote Job Service at UCSB", M. Krilanovich. RFC #477: NIC #14992, May 23, 1973.
13. 「UCSBでのリモート・ジョブサービス」、M.Krilanovich。 RFC#477: 1973年5月23日のNIC#14992。
Braden [page 19]
ブレーデン[19ページ]
一覧
スポンサーリンク
