RFC283 日本語訳
0283 NETRJT: Remote Job Service Protocol for TIPS. R.T. Braden. December 1971. (Format: TXT=18771 bytes) (Updates RFC0189) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
NETWORK WORKING GROUP R. T. BRADEN REQUEST FOR COMMENTS #283 UCLA/CCN NIC #8165 DECEMBER 20, 1971 CATEGORIES: D OBSOLETES: NONE UPDATES: RFC #189
コメント#283UCLA/CCN NIC#8165の1971年12月20日カテゴリを求めるワーキンググループR.T.ブレーデン要求をネットワークでつないでください: Dは以下を時代遅れにします。 なにも以下をアップデートしません。 RFC#189
NETRJT -- Remote Job Service Protocol for TIPS
----------------------------------------------
NETRJT--チップのためのリモート・ジョブサービスプロトコル----------------------------------------------
A. INTRODUCTION
------------
A。 序論------------
TIP's have very limited processing capability; their function is mainly limited to interfacing printer-keyboard devices to the Network using TELNET protocol. It will also be possible to have a tape drive on a TIP, using a subset of the count form of DTP (see RFC #264). However, TIP's cannot and will not support either DTP or FTP (see RFC #265) in general. Therefore, TIP users are excluded from using any existing remote job entry protocol (e.g. CCN's NETRJS - see RFC #189).
TIPのものには、非常に限られた処理能力があります。 それらの機能はTELNETプロトコルを使用することでプリンタキーボードデバイスをNetworkに連結するのに主に制限されます。 また、TIPにテープドライブを持っているのも可能でしょう、DTPのカウントフォームの部分集合を使用して(RFC#264を見てください)。 しかしながら、TIPのものは、サポートすることができないで、一般に、DTPかFTPのどちらかをサポートしないでしょう(RFC#265を見ます)。 したがって、TIPユーザは、どんな既存のリモートジョブエントリプロトコルも使用するので、除かれます(例えば、CCNのNETRJS--RFC#189を見てください)。
It appears, however, that it may be feasible in the future to use TIP's for remote job entry in one or more of the following three ways:
しかしながら、リモートジョブエントリに以下の3つの方法の1つ以上でTIPを使用するのが将来可能であるかもしれないように見えます:
(a) Attach local card readers, line printers, and card punches
directly to TIP ports. These devices would use a TELNET-like*
format and frame their characters with Start/Stop bits. BBN
can now supply a suitable 200 LPM printer, and is searching for
suitable readers and punches.
(a) 地方のカードリーダ、ラインプリンタ、およびカードパンチを直接TIPポートに取り付けてください。 これらのデバイスは、TELNETのような*形式を使用して、Start/ストップビットで彼らの性格を罪に陥れるでしょう。 BBNは現在適当な200LPMプリンタを供給できて、適当な読者とパンチを捜し求めています。
(b) Connect a remote batch terminal to a full-duplex TIP port via
a communication line. BBN is looking into this.
(b) 通信回線を通して全二重TIPポートにリモートバッチ端末をつなげてください。 BBNはこれを調べています。
(c) Use the tape drive, and do card-to-tape and/or tape-to-print
on another computer.
(c) テープドライブを使用してください、そして、別のコンピュータでカードからテープ、そして/または、印刷するテープをしてください。
BBN hopes to make case (b) look exactly like (a) to the server host. That is, the remote batch terminal will send to and receive from the server in a TELNET-like format*; the printer, card reader, punch, and operator console connections will all use different sockets but one hardware port at the TIP, which will map multiple sockets into the one port.
BBNは、ケース(b)をちょうど(a)をサーバー・ホストに似させることを望んでいます。 すなわち、リモートバッチ端末は、サーバからTELNETのような形式*で発信して、受信されるでしょう。 プリンタ、カードリーダ、パンチしてください。そうすれば、オペレータコンソール接続は皆、TIPの異なったソケットにもかかわらず、1つのハードウェアポートを使用するでしょう。(TIPは複数のソケットを1つのポートに写像するでしょう)。
NOTE: By "TELNET-like format", we mean: (a) _CR_LF_ used to delimit
logical records (lines or cards), and (b) the ASCII or EBCDIC
format effector control characters used for carriage control
in the printer stream. It does _not_ necessarily imply ASCII
character codes.
以下に注意してください。 「TELNETのような形式」で、私たちは以下を言っています。 (a) _CR_LF_は以前はよく論理レコード(系列かカード)、およびASCIIかEBCDIC書式制御文字制御文字が改行制御にプリンタストリームに使用した(b)を区切っていました。 それはどんな_も必ず含意するというわけではない_にASCII文字コードをします。
[Page 1]
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by BBN Corp. under the ]
[ direction of Alex McKenzie. 12/96 ]
[1パージュ][このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームであった]、[BBN社の下によるオンラインRFCアーカイブ、][ アレックス・マッケンジーの方向。 12/96 ]
This document describes NETRJT, a modification of CCN's NETRJS protocol specifically to provide remote job entry service to TIP's using one of the methods (a), (b), or (c). NETRJT follows the general model of NETRJS: use TELNET protocol over a primary or "operator" connection pair, and open simplex secondary connections for data transfer of job stream input and output. (We also considered the possibility of using the Divert Output mechanism of the TIP for sending remote job output over the operator connection, and an analogous mechanism for input. However, in discussion with Alex McKenzie, it was agreed that sharing the operator connections has little merit and causes lots of problems).
このドキュメントはNETRJT(特にTIPがメソッド(a)、(b)、または(c)の1つを使用することに対するリモートジョブエントリサービスを提供するCCNのNETRJSプロトコルの変更)について説明します。 NETRJTはNETRJSの一般的なモデルに従います: ジョブストリーム入出力のデータ転送に予備選挙か「オペレータ」接続組、およびオープンなシンプレクスセカンダリ接続の上でTELNETプロトコルを使用してください。 (また、私たちは、送付にTIPのDivert Outputメカニズムを使用する可能性がオペレータ接続の上のリモート・ジョブ出力と、入力のための類似のメカニズムであると考えました。 しかしながら、アレックス・マッケンジーとの議論では、オペレータ接続を共有すると、長所がほとんど持たれないで、多くの問題が引き起こされるのに同意されました。).
NETRJT differs in two principal ways from NETRJS:
NETRJTはNETRJSと2つの主要な方法において異なります:
1. The NETRJT server process initiates the data transfer
connections, under control of commands from the remote
operator console. On the other hand, under NETRJS the
remote user process has responsibility for initiating
the opening of secondary data transfer connections; the
NETRJS server simply listens on these sockets.
1. NETRJTサーバプロセスはリモートオペレータコンソールからコマンドのコントロールの下でデータ転送コネクションを開始します。 他方では、NETRJSの下では、リモート・ユーザープロセスはセカンダリデータ転送コネクションの始まりを開始することへの責任を持っています。 NETRJSサーバはこれらのソケットの上に単に聴かれます。
2. NETRJT provides the TELNET-like format defined above for
data transfer, as well as the TIP-tape DTP format. NETRJS,
on the other hand, is restricted to counts to delimit logical
records within DTP-like transactions, and ASA carriage control.
2. NETRJTはデータ転送のために上で定義された、TELNETのような書式、およびTIP-テープDTP形式を提供します。 他方では、NETRJSは、DTPのようなトランザクション、およびASA改行制御の中で論理レコードを区切るためにカウントに制限されます。
There are some other minor differences. For example, (1) the NETRJT server takes responsibility for folding output records when they exceed a size specified by a user command; under NETRJS, this was the user process' responsibility. (2) There are NETRJT operator commands to set the record format, record size, and code for each data transfer connection. NETRJS made the first two fixed properties of a particular terminal id, and deter- mined the last by the choice of ICP socket. These differences imply remote operator commands in NETRJT in addition to those of NETRJS. The operator must be able to (1) cause NETRJT to open a secondary connection to a TIP socket, and (2) specify the data transfer protocol, maximum logical record length, and/or transmission code. These NETRJT commands are discussed in the following section.
ある他の小異があります。 (1) 例えば、ユーザコマンドで指定されたサイズを超えていると、NETRJTサーバは折りたたみの出力記録に責任を取ります。 NETRJSの下では、これはユーザ・プロセスの責任でした。 (2) レコード形式、レコード・サイズ、およびコードを各データ転送コネクションに設定するために、NETRJTオペレータコマンドがあります。 NETRJSが特定の端末のイドの最初の2個の固定資産を作った、思いとどまらせる、ICPソケットの選択で最終を採掘しました。 これらの違いはNETRJSのものに加えてNETRJTのリモートオペレータコマンドを含意します。 (2) オペレータはTIPソケットにセカンダリ接続を開く(1) 原因NETRJTにできるに違いありません、そして、データ転送プロトコル、最大の論理レコード長、そして/または、伝送コードを指定してください。 以下のセクションでこれらのNETRJTコマンドについて議論します。
CCN plans to proceed with implementation of a NETRJT server with the goal of completing an initial version by March 15, 1972. This initial version may support only DTP=BS or TT, and RECFM=TELNET or RECORDS; other options will be added as the need arises. We welcome comments and suggestions.
CCNは、1972年3月15日までに初期のバージョンを完成するという目標のためにNETRJTサーバの実装を続けるのを計画しています。 この初期のバージョンはDTP=BSかTTと、RECFM=TELNETかRECORDSだけをサポートするかもしれません。 別の選択肢は必要に応じて加えられるでしょう。 私たちはコメントと提案を歓迎します。
[Page 2]
In the longer term, we believe that the NETRJT protocol described
here should be considered as the first draft of a Network standard for
remote job entry via TIP's. In its present form, NETRJT owes much to
the ideas and comments of Alex McKenzie (BBN), Jon Postel (NMC), Jim
White (UCSB), and Steve Wolfe (CCN).
より長い期間による[2ページ]、私たちはここで説明されたNETRJTプロトコルがTIPを通したリモートジョブエントリのNetwork規格の最初の草稿であるとみなされるべきであると信じています。 現行様式では、NETRJTはアレックス・マッケンジー(BBN)、ジョン・ポステル(NMC)、ジム・ホワイト(UCSB)、およびスティーブ・ウルフ(CCN)の考えとコメントから多くを借りています。
B. NETRJT COMMANDS
---------------
B。 NETRJTコマンド---------------
NETRJT provides the following commands over the remote operator connection, in addition to the NETRJS operator commands (see Appendix D of RFC #189). The symbol "#" denotes one or more spaces. We will use the IBM meta-language to describe the command syntax. The literal text shown here in upper case may, in fact, be entered in either upper or lower case.
NETRJTはリモートオペレータ接続の上に以下のコマンドを提供します、NETRJSオペレータコマンドに加えて(RFC#189のAppendix Dを見てください)。 「#」というシンボルは1つ以上の空間を指示します。 私たちは、コマンド構文について説明するのにIBMメタ言語を使用するつもりです。 事実上、ここ、大文字で示された文字通りのテキストは上側の、または、低いケースに入れられるかもしれません。
1. Opening a Stream
----------------
1. ストリームを開きます。----------------
/ \
| PR [INTER] | _ _
| | | |
O [PEN] # < PU [NCH] >| (jobname) | [ =socket-number[ /host-name ]]
| | | |
| R [EADER] | | (*) |
\ / |_ _|
/ \ | PR[埋葬します]| _ _ | | | | ○ [ペン]#<Pu[NCH]>| (jobname) | [=ソケット番号[/ホスト名]]| | | | | R[EADER]| | (*) | \ / |_ _|
If the specified device does not already have an open connection, the NETRJT server will request connection to the specified socket. The optional "(jobname)" para- meter is used to specify a particular job by name; for more information on the semantics of this parameter, see the discussion of input and output operations below. The "/host-name" parameter, to be implemented later, is intended to allow the file to be at a host different from both user and server hosts. We include it here only to suggest a syntax.
指定されたデバイスにオープンな接続が既にないと、NETRJTサーバは指定されたソケットに接続を要求するでしょう。 任意「(jobname)」というのパラメーターは名前の特定の仕事を指定するのに使用されます。 このパラメタの意味論の詳しい情報に関しては、以下での入出力操作の議論を見てください。 /は、後で実装されるために」 パラメタをホストと同じくらい命名して、ファイルがユーザとサーバー・ホストの両方と異なったホストにあるのを許容することを意図します。 私たちはここでそれを入れますが、構文を示します。
The socket number may have a one-letter suffix D, H, or O to mean decimal, hex, or octal. Octal is the default, so the O suffix may be omitted. If BBN establishes standardized TIP sockets for specific unit record devices, the socket number parameter could be omitted when the standard socket number is intended.
ソケット番号には、小数、十六進法、または8進を意味するために、1文字接尾語D、H、またはOがあるかもしれません。 8進がデフォルトであるので、O接尾語は省略されるかもしれません。 標準のソケット番号が意図するとき、BBNが特定のユニットレコード装置のために標準化されたTIPソケットを設立するなら、ソケット数のパラメタは省略されるかもしれません。
[Page 3]
2. Closing a Stream
----------------
[3ページ] 2。 ストリームを閉じます。----------------
_ _
| # PR [INTER] |
| |
CL [OSE] | # PU [NCH] | [,A [CCEPT]]
| |
| # R [EADER] |
|_ _|
_ _ | # PR[埋葬します]| | | Cl[大証]| # Pu[NCH]| [[CCEPT]]| | | # R[EADER]| |_ _|
This command closes the specified data transfer connection. The ACCEPT option is used to signal the server that it may discard output it has transmitted, or that it has received a complete stack of job input. See discussion in next section. The device specification (PR, PU, or R) may be omitted if only one device stream is currently open.
このコマンドは指定されたデータ転送コネクションを終えます。 ACCEPTオプションは、伝えた出力を捨てるかもしれないか、または仕事の入力の完全なスタックを受けたとサーバに合図するのに使用されます。 次のセクションの議論を見てください。 1つのデバイスストリームだけが現在開くなら、デバイス仕様(PR、PU、またはR)は省略されるかもしれません。
3. Setting Format and Device Characteristics
-----------------------------------------
3. 形式とデバイスの特性を設定します。-----------------------------------------
In each of the following variants of the RJT commands, the parameter
"device" is one of "PR [INTER]", "PU [NCH]", or "R [EADER]".
/ \
RJT # D [TP] (device) = < B [S] >
| T [T] |
| D [TP] |
\ /
それぞれのRJTコマンドの以下の異形では、「デバイス」というパラメタは「PR[埋葬する]」、「Pu[NCH]」、または「R[EADER]」の1つです。 /\RJT#D[TP](デバイス)は<B[S]>と等しいです。| T[T]| | D[TP]| \ /
BS: an unstructured byte stream.
BS: 不統一なバイト、流れてください。
TT: the TIP-tape transfer protocol (essentially
the count form of Network DTP).
TT: TIP-テープ転送プロトコル(本質的にはNetwork DTPのカウントフォーム)。
DTP: the Network standard DTP, complete with a modes-
available handshake. This form is not useful
for TIP's but is included here in anticipation
of the general Network standard RJE protocol.
DTP: モードの利用可能な握手で完全なNetwork標準のDTP。 このフォームは、TIPのものの役に立ちませんが、一般的なNetwork標準のRJEプロトコルを予測してここに含まれています。
/ \
RJT # R [ECFM] (device) = < T [ELNET] >
| A [SA] |
| R [ECORDS] |
| C [OMPRESSED] |
\ /
/\RJT#R[ECFM](デバイス)は<T[ELNET]>と等しいです。| [SA]| | R[ECORDS]| | C[OMPRESSED]| \ /
[Page 4]
The following choice of options is tentative, as it is presently
unclear just what record formats will be useful for TIP tapes or
remote batch terminals connected to TIP's.
[4ページ] オプションの以下の選択は一時的です、まさしくどんなレコード形式がTIPのものにつなげられたTIPテープかリモートバッチ端末の役に立つかが、現在不明瞭であるときに。
TELNET: the "TELNET-like format": _CR_LF_ used to delimit
logical records in all streams, and format effector
control characters (_CR_, _LF_, _FF_) for printer
carriage control.
telnet: 「TELNETのような形式」: _CR_LF_はプリンタ改行制御のために以前はよくすべてのストリーム、および書式制御文字制御文字(__CR_、_LF_、FF_)の論理レコードを区切っていました。
ASA: CRLF used to delimit logical records, but an ASA
carriage control character is sent as the first
character of each printer record. (This option
may be useful for remote batch terminals which
expect ASA carriage control).
アサ: CRLFは以前はよく論理レコードを区切っていましたが、それぞれのプリンタ記録の最初のキャラクタとしてASAキャリッジ制御文字を送ります。 (このオプションはASA改行制御を予想するリモートバッチ端末の役に立つかもしれません。)
RECORDS: the "truncated" format of NETRJS: an id byte, a
count byte, and then the string, with ASA carriage
control in each printer record.
記録: NETRJSの「端が欠けている」形式: イドバイト、カウントバイト、および次にASA改行制御は各プリンタにあるストリングが記録します。
COMPRESSED: the "compressed" format of NETRJS (see RFC #189 for
details). (Compression will be useful for batch
terminals connected remotely to Tip's) .
圧縮される: NETRJS(詳細に関してRFC#189を見る)の「圧縮された」形式。 (圧縮はTipのものに離れてつなげられたバッチ・ターミナルの役に立ちます) .
RJT # SIZE (device) = integer
RJT#SIZE(デバイス)は整数と等しいです。
This command sets the maximum logical record length for the specified device. NETRJT will automatically fold any records exceeding this size. Default sizes are:
このコマンドは指定されたデバイスに最大の論理レコード長を設定します。 NETRJTは自動的にこのサイズを超えているどんな記録も折り重ねるでしょう。 デフォルトサイズは以下の通りです。
PR: 120
PR: 120
PU: 80
Pu: 80
R : 80
/ \
RJT # CODE (device) = < A [SCII] >
| E [BCDIC] |
\ /
R: 80/\RJT#コード(デバイス)=<は[SCII]>です。| E[BCDIC]| \ /
This command sets the code to be used.
このコマンドは、コードに使用されるように設定します。
[Page 5]
C. USING NETRJT AT CCN
-------------------
[5ページ] CCNでNETRJTを使用するC.-------------------
1. Getting Started
---------------
1. 使用前に---------------
a. Perform ICP to server TELNET (socket 1).
a。 サーバTELNET(ソケット1)にICPを実行してください。
b. Execute command "RJT", yielding ready message from NETRJT.
b。 NETRJTから持ち合わせのメッセージをもたらして、コマンド"RJT"を実行してください。
c. Issue RJS SIGNON command.
c。 問題RJS SIGNONは命令します。
d. These steps result in a standard full-duplex TELNET connection
for an RJS remote operator console. The user can issue commands
to learn the status of his jobs, send messages, reroute and abort
jobs, etc.
d。 これらのステップはRJSのリモートオペレータコンソールのための標準の全二重TELNET接続をもたらします。 ユーザは彼の仕事の状態を学んで、メッセージを送って、コースを変更して、仕事を中止するコマンドなどを発行できます。
2. Retrieving Output
-----------------
2. 出力を検索します。-----------------
a. The TIP user captures a local output device and then executes
the NETRJT OPEN command for the PRINTER or PUNCH. For example,
if the connection is not yet open, then either of:
a。 TIPユーザは、PRINTERかパンチのために地方の出力装置をキャプチャして、次に、NETRJT OPENコマンドを実行します。 例えば、そして、以下のどちらか接続がまだオープンでないなら
O PR=socket
○ PRはソケットと等しいです。
O PR(*)=socket
○ PR(*)はソケットと等しいです。
opens a printer connection and selects the first job in the
printer queue for this terminal id.
この端末のイドのためにプリンタ接続を開いて、プリンタのキューにおける最初の仕事を選択します。
O PR(jobname)=socket
○ PR(jobname)はソケットと等しいです。
similarly opens a connection but selects a specified job's
output. In either case, if output is not yet available the
connection remains open but idle, and the output is sent when
it does appear. If the socket number is omitted and the
connection is not yet open, the server will prompt for a
socket number.
同様に接続を開きますが、指定された仕事の出力を選択します。 どちらの場合ではも、出力がまだ利用可能でないなら、接続は開きますが、活動していないままでいます、そして、現れるとき、出力を送ります。 ソケット番号が省略されて、接続がまだオープンでないなら、サーバはソケット番号のためにうながされるでしょう。
b. If the specified output device already has an open connection,
either of the open commands:
b。 指定された出力装置にオープンな接続が既にあるなら、戸外のどちらかが命令します:
O PR
○ PR
O PR(jobname)
○ PR(jobname)
[Page 6]
may be issued to _accept_ (see e. below) the last job's output
and select and send another job's output. If the connection
is already open, the open command may still specify "=socket",
but if the specified socket does not match that currently open
there will be an error message.
[6が]発行されるかもしれないページは、別口の仕事の出力を最後の仕事が出力した_(以下のe.を見る)を_に受け入れて、選択して、送ります。 接続が既にオープンであるなら、開いているコマンドはまだ「=ソケット」を指定しているかもしれませんが、指定されたソケットがそんなに現在の戸外に合っていないと、エラーメッセージがあるでしょう。
c. While the output stream is idle, the user can issue RJT
commands with DTP, RECFM, CODE and/or SIZE parameters.
c。 出力ストリームが無駄である間、ユーザはDTP、RECFM、CODE、そして/または、SIZEパラメタでRJTにコマンドを発行できます。
d. When the specified output is available, the server will
send a stream of print line (or punched card) images. The
user may issue the following RJS stream control commands
(see NIC 7182 and 7183 for more information on RJS commands).
d。 指定された出力が利用可能であるときに、サーバは印刷系列(または、パンチカード)イメージのストリームを送るでしょう。 ユーザは以下のRJSストリーム制御コマンドを発行するかもしれません(RJSコマンドの詳しい情報に関してNIC7182と7183を見てください)。
1. BACKSPACE: repeats roughly the last page of printed output.
1. バックスペースキーを押して印字位置を一字分戻ります: およそプリント出力の終面を繰り返します。
2. RESTART: restarts output at the beginning of the current
SYSOUT data set or ("JOB" option) at the beginning
of the job.
2. 以下を再開してください。 現在のSYSOUTデータセットの始めの出力か仕事の始めの(「仕事」オプション)を再開します。
3. CANCEL: deletes rest of current SYSOUT data set, or
(",JOB" option) the entire job except account-
ing information.
3. 以下を取り消してください。 または、現在のSYSOUTデータセットの残りを削除する、(「」 オプション) 仕事全体が除く仕事は、ingが情報であることを説明します。
4. DEFER: stops transmission of the current job and returns
it to the queue, marked "deferred". Can be
restarted later, with a "backspace" ("RESET
jobname" command) or from the beginning
("RESTART jobname" command).
4. 延期します: 現在の仕事の送信を止めて、「延期されている」とマークされた待ち行列にそれを返します。 後で("RESET jobname"コマンド)か始め("RESTART jobname"コマンド)からの「バックスペースキーを押して印字位置を一字分戻ってください」で再開できます。
e. The server does not discard job output until it is fully
transmitted to the TIP and the user has _accepted_ it. If the
user issues a "CLOSE device" or the connection breaks
accidentially (e.g. due to software or hardware failure in
either host) before the output is accepted, the server saves
the output with an implied BACKSPACE. When the user later reopens
the connection and again selects this job (either explicitly by
name or by calling for the next job), it will be retransmitted,
repeating the last page. The user can also defer or restart the
job output before reopening the connection. Note that CLOSE
without the ACCEPT option is generally a "panic" control to stop
the output stream if the printer paper jams, etc.
e。 それがTIPに完全に伝えられるまで、サーバは仕事の出力を捨てません、そして、ユーザは_を受け入れさせます。_それ。 ユーザが「CLOSEデバイス」を発行するか、または出力を受け入れる前に接続がaccidentiallyに(例えば、どちらかのホストでのソフトウェアかハードウェアの故障による)中断しているなら、サーバは暗示しているBACKSPACEとの出力を取っておきます。 ユーザが後で接続を再開させて、再びこの仕事を選択するとき(次の仕事のために明らかに命名するか、または呼びます)、それは再送されるでしょう、終面を繰り返して。 また、接続を再開させる前に、ユーザは、仕事の出力を延期するか、または再開できます。 プリンタ紙のジャムであるのなどなら一般に、ACCEPTオプションのないCLOSEが「パニック」コントロールであることに注意して、出力ストリームを止めてください。
f. Transmitted output will be considered accepted by the user if:
f。 ユーザで受け入れる、伝えられた出力が考えられる:
1. The user issues a new OPEN command for that device.
1. ユーザはそのデバイスのための新しいオープン命令を発行します。
[Page 7]
2. The user issues a "CLOSE device, ACCEPT" (e.g. "CL#PR,A")
command for that device. This command will be held pending
until job output in progress has completed. After the last
RFNM is received, the connection will be closed and the job
output discarded at the server end.
[7ページ] 2。 ユーザは「CLOSEデバイス、ACCEPT」(例えば、「Cl#PR、A」)にそのデバイスのためのコマンドを発行します。 このコマンドは進行中の出力が完了した仕事まで未定であるとして保持されるでしょう。 最後のRFNMが受け取られていた後に、接続は閉じるようになって、仕事の出力はサーバ終わりに捨てられます。
3. The original OPEN command specified "(*)", i.e. an asterisk
for jobname. This implies that the device stream is going
to be running continuously and that the user does not want
to explicitly request each output job or to accept each
one. Thus, if the stream is opened "(*)", then the server
assumes each job is accepted when the RFNM returns from the
last block.
3. オリジナルのオープン命令は「(*)」、すなわち、アスタリスクをjobnameに指定しました。 デバイス小川が絶え間なく走って、ユーザは、明らかにそれぞれの出力仕事を要求したくはありませんし、これがそれぞれを受け入れたがっていないつもりです。 したがって、ストリームが開かれるなら「(*)」という、サーバは、RFNMが最後のブロックから戻るとき、各仕事が受け入れられると仮定します。
3. Sending Input
-------------
3. 送付入力-------------
(a) The user sends the following remote operator command to the server:
(a) ユーザは以下のリモートオペレータコマンドをサーバに送ります:
OPEN READER=socket
オープンな読者はソケットと等しいです。
(This may be shortened to "O R=socket"). The server will send
an RFC to the user's card reader socket on which his TIP should
be listening. The server will issue an operator message when
the connection is open. The connection will be considered _idle_
until the first card image is received by the server. The OPEN
command will be ignored if the connection is already open, or
if an earlier open request is pending.
(これは「○ Rはソケットと等しく」短くされるかもしれません。) サーバは彼のTIPが聴いているはずであるユーザのカードリーダソケットにRFCを送るでしょう。 接続がオープンであるときに、サーバはオペレータメッセージを発行するでしょう。 接続は_使用されていない_であるとサーバで最初のカードイメージを受け取るまで考えられるでしょう。接続が既にオープンであるか、または以前の開いている要求が未定であるなら、オープン命令は無視されるでしょう。
(b) Before or after the open, but while the connection is idle, the
user may issue RJT commands to set the record format, data trans-
fer protocol, code, and/or maximum record size to different values.
(b) 以前か後に、戸外であり、接続が無駄である間、ユーザはレコード形式を設定するRJTコマンド、データの移-ferなプロトコル、コード、そして/または、最大のレコード・サイズを異価に発行するかもしれません。
(c) The user sends in a stream of card images which constitute one
or more jobs. The server will discard the spooled images for a
job without processing them if the user issues a CANCEL READER
command or if the connection breaks (e.g. due to software or
hardware failures in either host) before the job is accepted
for processing. The stream then becomes idle again.
(c) ユーザは1つ以上の仕事を構成するカードイメージのストリームを送ります。 ユーザがキャンセル読者命令を発行するか、または接続が中断しているなら(例えば、どちらかのホストでのソフトウェアかハードウェアの故障のため)処理のために仕事を受け入れる前にそれらを処理しないで、サーバは仕事のためのスプールさせられたイメージを捨てるでしょう。 そして、ストリームは再び活動していなくなります。
[Page 8]
(d) A spooled job will be accepted by the server only when one of
the following occurs:
[8ページ] (d) 以下の1つが起こるときだけ、サーバはスプールさせられた仕事を受け入れるでしょう:
1. A server-dependent end-of-job card (e.g. "//null" at CCN)
is received by the server. The last job is accepted, and
the stream becomes idle until another card is received.
1. 「サーバ依存するエンド・オブ・ジョブ・カード、(」 例えば、//ヌル、」、CCN)、サーバで受け取って. 最後の仕事を受け入れて、別のカードが受け取られているまで、ストリームは活動していなくなります。
2. A server-dependent beginning-of-job card (e.g. a "JOB" card
at CCN) is received by the server. The previous job is
accepted but the stream does not become idle at this time.
2. サーバはサーバ依存する仕事の始まりのカード(例えば、CCNの「仕事」というカード)を受け取ります。前の仕事を受け入れますが、このとき、ストリームは活動していなくなりません。
3. The user issues a CLOSE READER,ACCEPT (or "CL#R,A") com-
mand to the server. The stream is closed.
3. ユーザはCLOSE読者、ACCEPT(または、「Cl#R、A」)com- mandをサーバに発行します。ストリームは閉じられます。
(e) The user can issue a CLOSE READER ("CL#R") command to close the
stream. However, this command will be held pending by the server
until the stream is idle, unless the form "CLOSE READER,ACCEPT"
is issued. A CLOSE will cancel a pending OPEN command, and vice
versa. The server will send the remote operator a message when
a connection opens or closes.
(e) ユーザはCLOSE読者(「Cl#R」)にストリームを閉じるコマンドを発行できます。 しかしながら、ストリームが活動していなくなるまで、このコマンドはサーバによって未定であるとして保持されるでしょう、フォーム「読者を閉じてください、そして、受け入れてください」が発行されない場合。 CLOSEは未定のオープン命令を取り消すでしょう、そして、逆もまた同様です。 接続が開くか、または閉じると、サーバはリモートオペレータにメッセージを送るでしょう。
(f) Some servers (e.g. CCN) will extract the jobname for each input
job from the reader stream. However, the OPEN command may
specify a particular jobname, overriding that in the reader
stream. That is, the jobname from the OPEN command will replace
that appearing in the first job of the newly-opened stream. This
feature is merely a convenience, and was included mainly for
syntactic consistency between input and output. However, the use
of asterisk as a jobname has no meaning for the reader stream,
and will be ignored.
(f) いくつかのサーバ(例えば、CCN)がそれぞれの入力仕事のために読者ストリームからjobnameを抽出するでしょう。 しかしながら、読者ストリームでそれをくつがえして、オープン命令は特定のjobnameを指定するかもしれません。 すなわち、オープン命令からのjobnameは新たに開かれたストリームの最初の仕事におけるその排臨を取り替えるでしょう。 この特徴は、単に便利であり、主に入出力の間の構文の一貫性のために含まれていました。 しかしながら、jobnameに読者のための意味でないのがあるとき、アスタリスクの使用は、流れて、無視されるでしょう。
[Page 9]
[9ページ]
一覧
スポンサーリンク
