RFC105 日本語訳

0105 Network Specifications for Remote Job Entry and Remote Job OutputRetrieval at UCSB. J.E. White. March 1971. (Format: TXT=21938 bytes) (Updated by RFC0217) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文

Network Working Group                                     James E. White
Request for Comments: 105                         Computer Research Lab.
Category: Informational                         University of California
                                               Santa Barbara, California
                                                              March 1971

コメントを求めるワーキンググループジェームスE.ホワイトの要求をネットワークでつないでください: 105コンピュータ研究研究室。 カテゴリ: 1971年の情報のカリフォルニア大学のサンタバーバラ(カリフォルニア)行進

                       Network Specifications for
                            Remote Job Entry
                                  and
                      Remote Job Output Retrieval
                                at UCSB

リモートジョブエントリのためのネットワーク指定とUCSBでのリモート・ジョブ出力検索

     In the discussions that follow, 'byte' means 8 bits, with those
eight bits numbered 0-7 from left to right.

続く議論では、それらの8ビットが左から右まで0-7に付番されている状態で、'バイト'は8ビットを意味します。

I - Remote Job Entry (RJE)

私--リモートジョブエントリ(RJE)

     UCSB will accept input of pseudo card files for batch processing
at socket number x'200', site 3.  Network users should obtain an
account number from the UCSB Computer Center; account #1025,
programmer names 'UCLA', 'SRI', 'UTAH', etc. may be used during
checkout.  The 360/75 runs under OS MVT and HASP.  Users submit jobs
to HASP for scheduling and subsequent execution by OS through an
intermediary process hereafter called RJE which is addressed as socket
number x'200' and can be invoked through the Logger.  This section is
intended to provide programmers with the information necessary to
communicate with RJE; the is assumed familiar with the batch services
offered by the Computer Center, and with its job control language
(JCL) requirements.

UCSBはソケット番号xでバッチ処理するための'200'という疑似カードファイル、サイト3の入力を受け入れるでしょう。 ネットワーク利用者はUCSBコンピュータセンターから口座番号を得るべきです。 アカウント#1025、プログラマ名'UCLA'、'SRI'、'ユタ'などはチェックアウトの間、使用されるかもしれません。 OS MVTとHASPの下の360/75回の下痢。 ユーザは、計画をしていてその後の実行のために今後ソケット数のx'200'として記述されるRJEと呼ばれる仲介者の過程を通してOSでHASPに仕事を提出して、Loggerを通して呼び出すことができます。 このセクションがRJEとコミュニケートするために必要情報をプログラマに提供することを意図します。 コンピュータセンターによって提供されるバッチサービス、およびそのジョブ・コントロール・ランゲージに身近な(JCL)要件であると思われます。

     RJE conducts all Network transactions through the NCP, which
operates under the Host-Host protocol of 3 August 1970.  It expects
the first message it receives to be Type 0, discards the first eight
bits (the message type) assuming them to be zeros, and thereafter for
the life of the connection takes no notice of IMP-message boundaries.

RJEはNCPを通してすべてのNetwork取引を行います。NCPは1970年8月3日のHost-ホストプロトコルの下で作動します。 それらがゼロであると仮定しながら、それは、それが受け取る最初のメッセージがType0、最初の8ビット破棄であると予想します、そして、(メッセージタイプ)その後、接続の人生に、IMP-メッセージ限界の通知は全く取っていません。

I.A - Logging into RJE

I.A--RJEにログインすること。

     To submit one or more jobs for batch processing, the Network user
must establish a simplex connection with RJE.  RJE is core resident
only while such a simplex connection is established (i.e., while a
user is transmitting a file).  At all other times, it resides on
direct-access storage and must be invoked through the Logger.  A login
sequence can always be initiated by requesting connection to socket
x'200'.  RJE does not serve multiple users simultaneously.  This if a
connection request is made to that socket while RJE is in use, the NCP
will queue the request.  When the current file transmission is

バッチ処理のために1つ以上の仕事を提出するために、NetworkユーザはRJEとのシンプレクス接続を確立しなければなりません。 そのようなシンプレクス接続は単に確立されますが(すなわち、ユーザがファイルを送っている間)、RJEはコアの居住者です。 他のすべての回、それはランダムアクセス記憶装置のときに住んでいて、Loggerを通して呼び出さなければなりません。 ソケットx'200'に接続を要求することによって、ログイン系列をいつも開始できます。 RJEは同時に、複数のユーザに役立ちません。 接続要求であるならRJEが使用中である間、これをそのソケットにして、NCPは要求を列に並ばせるでしょう。 現在のファイルトランスミッションはいつですか。

White                                                           [Page 1]

RFC 105                       RJE at UCSB                     March 1971

UCSB行進1971年の白い[1ページ]RFC105RJE

complete, RJE will listen for and accept the next request (if any) in
its queue; if no requests are queued for it, it will terminate
execution, releasing the main storage it occupied.  At times when RJE
is not in core, the Logger listens on socket x'200', and will reject
the first call it receives, read RJE into core, and dispatch it.  RJE
will then list on that socket.  Thus to initiate a login sequence, the
user requests connection to socket x'200'.  If accepted, he is in
contact with RJE.  If rejected, he should reissue the connection
request; when accepted, he will be connected to RJE.  A second
rejection would indicate that the NCP's resources were exhausted.
Once the connection has been established, RJE will consider the user
logged in.

完全であることで、RJEは待ち行列で次の要求を聞こうとして、受け入れるでしょう(もしあれば)。 要求が全くそれのために列に並ばせられないなら、実行を終えて、それが占領した主記憶装置をリリースするでしょう。 RJEがコアにない時代に、Loggerはソケットの上にx'200'を聴いて、それが受ける準備ラッパを拒絶して、コアからRJEを読み取って、それを派遣するでしょう。 そして、RJEはそのソケットに記載するでしょう。 したがって、ログイン系列を開始するために、ユーザはソケットx'200'に接続を要求します。 受け入れるなら、彼はRJEに接触しています。 拒絶されるなら、彼は接続要求を再発行するべきです。 受け入れると、彼をRJEに接続するでしょう。 2番目の拒絶は、NCPのリソースが枯渇したのを示すでしょう。 接続がいったん確立されると、RJEはログインされたユーザを考えるでしょう。

     To prevent RJE from being monopolized by a single user, provision
is made within the software for terminating a connection if RJE is
ever required to wait more than a certain amount of time for a
transmission from the connected user.  For now, this time limit has
been set at one minute per record, but it may be shortened or
lengthened as required in the future.  Barring such termination, RJE
will maintain its connection to the user indefinitely.  Card images
will be accepted over the connection, and each one will be passed to
HASP as it is received.  The user is expected to close the connection
once his file has been transmitted.  RJE will interpret that action as
an end-of-file indication, and the user will be considered logged off.

RJEがシングルユーザーによって独占されているのを防ぐのに、RJEが今までにある時間より接続ユーザからトランスミッションを待たなければならないなら接続を終えるためのソフトウェアの中に備えます。 当分、このタイムリミットが1記録あたり1分に設定されていますが、それは、将来、必要に応じて短くされるか、または伸されるかもしれません。 そのような終了を除いて、RJEはユーザに接続を無期限に維持するでしょう。 接続の上にカードイメージを受け入れるでしょう、そして、それが受け取られているとき、それぞれをHASPに通過するでしょう。 彼のファイルがいったん送られるとユーザが接続を終えると予想されます。 ファイルの終りがログオフしたので、指示、およびユーザが考えられるRJEはその動作を解釈するでしょう。

I.B - The RJE Connection

I.B--RJE接続

     RJE expects the first byte of data it receives over the
connection established with it to be zeros, indicating message Type 0;
it discards this byte unexamined, and thereafter, attaches no
significance to IMP-message boundaries.  The second byte of data
received is interpreted as flags specifying the format of the data
(file) to follow.  The byte is interpreted as follows:

RJEは、それがそれで確立された接続の上に受け取るデータの最初のバイトがゼロであると予想します、メッセージType0を示して。 それはその後非審査されたこのバイトを捨てて、大使館員はIMP-メッセージ限界への意味ではありません。 続くようにデータ(ファイル)の形式を指定しながら弛むとき、受け取られたデータの2番目のバイトは解釈されます。 バイトは以下の通り解釈されます:

     Bits 0-1 = 00:  file follows as Class A (stream-oriented)
                     input.
              = 01:  not defined, should not occur.
              = 10:  file follows as Class B (variable-length
                     record) input.
              = 11:  file follows as Class C (fixed-length record)
                     input.
     Bits 2-7     :  not examined, should be zeros.

ビット0-1 = 00: ファイルはA(流れ指向の)が入力したClassとして従います。 = 01: 定義されていなくて、起こるべきではありません。 = 10: ファイルはB(可変長レコード)が入力したClassとして従います。 = 11: ファイルはC(固定長レコード)が入力したClassとして従います。 ビット2-7: ゼロであるべきです調べられないで。

Once made, this declaration prevails for the life of the connection.

いったん作られると、この宣言は接続の人生で広がっています。

     Regardless of the input class specified, the user transmits his
file as card images, each of which will be padded on the right with
blanks or truncated on the right to 80 bytes if necessary.  The file

指定された入力のクラスにかかわらず、ユーザはカードイメージとして彼のファイルを送ります。必要なら、それぞれ右で空白で水増しされるか、またはそれは80バイトへの右で先端を切られるでしょう。 ファイル

White                                                           [Page 2]

RFC 105                       RJE at UCSB                     March 1971

UCSB行進1971年の白い[2ページ]RFC105RJE

transmitted must be structured exactly as if it were being placed on
the card reader at the Computer Center.  A job card and all the other,
usual JCL must be present for each job in the file (batching of jobs
is permissible and is transparent to RJE).  For any job which requires
that special (non-resident) disk(s) and/or tape(s) to be mounted, a
special JCL card must be inserted immediately after the job card for
that job, and it must have the format:

伝える、まるでちょうどそれがコンピュータセンターにカードリーダに置かれているかのように構造化しなければなりません。 仕事のカード、およびすべての他の、そして、普通のJCLがファイルにおける各仕事のために存在していなければなりません(仕事のバッチングは、許されて、RJEにわかりやすいです)。 その特別な(非居住者)ディスク、そして/または、テープが取り付けられるのを必要とするどんな仕事においてもその仕事のための仕事のカード直後特別なJCLカードを挿入しなければなりません、そして、それには、形式がなければなりません:

        /*SETUP        vol-ser , vol-ser ,...
                              1         2

/*SETUP vol-ser、vol-ser… 1 2

where 'vol-ser ' is the volume serial number of a volume requiring
              i
mounting.  '/*SETUP' begins in column 1; 'vol-ser ' must begin in
                                                 1
column 16.  The job will then enter the System in a HASP hold status
until the required volume(s) can be mounted by the operator.  If the
user neglects to declare all such required volumes, his job is subject
to immediate cancellation.  All cards of the file which are not
contained in a SYSIN data set must consist of valid, EBCDIC
characters.

'vol-ser'がiの取り付けを必要とするボリュームのボリューム通し番号であるところ。 '/*SETUP'はコラム1で始まります。 'vol-ser'は1つのコラム16で始まらなければなりません。 そして、オペレータが必要なボリュームを取り付けることができるまで、仕事はHASP保持状態にSystemを入れるでしょう。 ユーザが、すべてのそのようなものがボリュームを必要としたと宣言するのを忘れるなら、彼の仕事は即座のキャンセルを受けることがあります。 SYSINデータセットに含まれていないファイルのすべてのカードが有効なEBCDICキャラクタから成らなければなりません。

I.B.1 - Class A (Stream-Oriented) Input

I.B.1--(流れ指向)の入力を分類してください。

    If input to RJE has been declared as Class A, the third byte of data
received over the connection by RJE is interpreted as a break character
declaration.  Each byte received thereafter is compared to that
character.  Any other character is taken to be the next byte of the
current card image.  Whenever the break character is encountered, the
previous byte is taken to be the last byte of the current card image,
which is then padded or truncated as required and passed to HASP.  Zero
or more non-break characters may occur between occurrences of the break
character.  Thus when Class A input is specified, data transmitted to
RJE shall have the following form:

RJEへの入力がClass Aとして宣言されたなら、RJEによって接続の上に受け取られたデータの3番目のバイトは区切り文字宣言として解釈されます。 その後受け取られた各バイトはそのキャラクタにたとえられます。 現在のカードイメージの次のバイトになるようにいかなる他のキャラクタも取ります。 区切り文字が遭遇するときはいつも、現在のカードイメージの最後のバイトになるように前のバイトを取ります。(カードイメージは、次に、水増しされるか、必要に応じて先端を切られて、またはHASPに通過されます)。 ゼロか、より多くの非区切り文字が区切り文字の発生の間に起こるかもしれません。 Aが入力したClassが指定されるとき、したがって、RJEに送られたデータで、以下は形成されるものとします:

    1       1       1            variable         1
+-------+-------+-------+  / +------//--------+-------+ \
|       |       | BREAK | /  |                | BREAK |  \
| x'00' | x'00' | CHAR. | \  |  CARD  IMAGE   | CHAR. |  / ...
+-------+-------+-------+  \ +------//--------+-------+ /

1 1 1、可変1+-------+-------+-------+ / +------//--------+-------+ \ | | | 中断| / | | 中断| \ | x'00'| x'00'| 焦げてください。 | \ | カードイメージ| 焦げてください。 | / ... +-------+-------+-------+ \ +------//--------+-------+ /

where the length of each field has been specified in bytes.  Zero or
more occurrences of the quantity in parentheses [angle brackets] may be
transmitted before the connection is closed by the user.

それぞれの分野の長さがバイトで指定されたところ。 ユーザが接続を閉店させる前に括弧[角ブラケット]の量のゼロか、より多くの発生が伝えられるかもしれません。

I.B.2 - Class B (Variable-Length Record) Input

I.B.2--クラスB(可変長レコード)入力

     If input to RJE has been declared as Class B, then all input after

RJEへの入力が後にClass Bとして宣言されて、次に、すべて入力されているなら

White                                                           [Page 3]

RFC 105                       RJE at UCSB                     March 1971

UCSB行進1971年の白い[3ページ]RFC105RJE

the initial two bytes is expected to consist of a contiguous string of
variable length records, each consisting of a one-byte op code (the op
code should be x'01'), a two-byte length field which specifies the
unsigned length in bits of the variable-length text field which follows.
The text field may be zero or more bytes in length; the length field
must contain an integer which is a multiple of 8.  The text field
represents one card image, which is padded or truncated by RJE as
required and passed to HASP.  Thus when Class B input is specified, data
transmitted to RJE shall have the form:

初期の2バイトが可変長レコードの隣接のストリングから成ると予想されます、1バイトのオペコード(オペコードはx'01'であるべきである)(従う可変長のテキストフィールドのビットの無記名の長さを指定する2バイトの長さの分野)からそれぞれ成って テキストフィールドはゼロであるかもしれませんか以上は長さはバイトです。 長さの分野は8の倍数である整数を含まなければなりません。 テキストフィールドは1つのカードイメージを表します。(それは、水増しされるか、必要に応じてRJEによって先端を切られて、またはHASPに通過されます)。 Bが入力したClassが指定されるとき、したがって、RJEに送られたデータはフォームを持っているものとします:

    1       1            1       2      L bits
+-------+-------+  / +-------+-------+-----//-----+ \
|       |       | /  |       |       |    TEXT    |  \
| x'00' | x'80' | \  | x'01' |   L   | card image |  / ...
+-------+-------+  \ +-------+-------+-----//-----+ /

1 1 1 2Lビット+-------+-------+ / +-------+-------+-----//-----+ \ | | | / | | | テキスト| \ | x'00'| 'x80年'| \ | x'01'| L| カードイメージ| / ... +-------+-------+ \ +-------+-------+-----//-----+ /

where the length of each field has been specified in bytes, except where
stated to the contrary.  Zero or more occurrences of the quantity in
parentheses [angle brackets] may be transmitted before the connection is
closed.

それぞれの分野の長さが述べられているところ以外のそれと反対なバイトで指定されたところ。 接続が閉じるようになる前に括弧[角ブラケット]の量のゼロか、より多くの発生が伝えられるかもしれません。

I.B.3 - Class C (Fixed-Length Record) Input

I.B.3--クラスC(固定長レコード)入力

     If input to RJE has been declared as Class C, then all input after
the initial two bytes is expected to consist of a contiguous string of
fixed-length, 80-byte card images.  Thus, when Class C input is
specified, data transmitted to RJE shall have the form:

RJEへの入力がClass Cとして宣言されたなら、初期の2バイトの後のすべての入力が固定長(80バイトのカードイメージ)の隣接のストリングから成ると予想されます。 Cが入力したClassが指定されるとき、したがって、RJEに送られたデータはフォームを持っているものとします:

    1       1                  80
+-------+-------+  / +--------------------+ \
|       |       | /  |                    |  \
| x'00' | x'C0' | \  |     card image     |  / ...
+-------+-------+  \ +--------------------+ /

1 1 80 +-------+-------+ / +--------------------+ \ | | | / | | \ | x'00'| x'C0'| \ | カードイメージ| / ... +-------+-------+ \ +--------------------+ /

where the length of each field has been specified in bytes.  Zero or
more occurrences of the quantity in parentheses [angle brackets] may be
transmitted before the connection is closed.

それぞれの分野の長さがバイトで指定されたところ。 接続が閉じるようになる前に括弧[角ブラケット]の量のゼロか、より多くの発生が伝えられるかもしれません。

II - Remote Job Output Retrieval (RJOR)

II--リモート・ジョブ出力検索(RJOR)

     Class A SYSOUT output from jobs submitted through RJE for batch
processing at UCSB may be obtained by contacting socket x'300', site 3,
provided that when the job was submitted, the character 'T' appeared as
the eighth positional accounting parameter on the job card.  Output is
retrieved upon request and relayed to the Network user by a process
hereafter called RJOR which is addressed as socket x'300'.  RJOR can be
invoked through the Logger.  This section is intended to provide
programmers with the information necessary to communicate with RJOR.

ソケットx'300'に連絡することによって、UCSBでバッチ処理するためにRJEを通して提出された仕事からのクラスA SYSOUT出力を入手するかもしれません、サイト3、仕事を提出したとき、キャラクタ'T'が8番目の位置の会計パラメタとして仕事のカードに載っていたならば。 出力は、今後ソケットx'300'として記述されるRJORと呼ばれる工程で、要求のときに検索されて、Networkユーザにリレーされます。 Loggerを通してRJORを呼び出すことができます。 このセクションがRJORとコミュニケートするために必要情報をプログラマに提供することを意図します。

White                                                           [Page 4]

RFC 105                       RJE at UCSB                     March 1971

UCSB行進1971年の白い[4ページ]RFC105RJE

     RJOR conducts all Network transactions through the NCP, which
operates under the Host-Host protocol of 3 August 1970.  RJOR expects
the first message it receives to be Type 0, discards the first byte,
assuming it to be zeros, and thereafter for the life of the connection
takes no notice of IMP-message boundaries.  Similarly, the first message
sent by RJOR is of Type 0: the first byte consists of zeros, and
thereafter for the life of the connection, IMP-message boundaries are
not significant.

RJORはNCPを通してすべてのNetwork取引を行います。NCPは1970年8月3日のHost-ホストプロトコルの下で作動します。 RJORは、それが受け取る最初のメッセージがType0であると予想して、破棄は最初のバイトです、IMP-メッセージ限界に注意を払わないと仮定して。 同様に、RJORによって送られた最初のメッセージはType0のものです: 最初のバイトはゼロから成ります、そして、接続の人生には、その後、IMP-メッセージ限界は重要ではありません。

II.A - Logging into RJOR

II.A--RJORにログインすること。

     To obtain output from a batch-mode job, the Network user must
establish a full duplex connection with RJOR.  RJOR is core resident
only while in use (i.e., while control information or a file is being
transmitted to or from a user, or while RJOR is waiting for a previously
requested output file (or files)).  At all other times, it resides on
direct-access storage and must be invoked through the Logger.  A login
sequence can always be initiated by requesting connection to socket
x'300'.  If a connection request is made to that socket while another
user is being logged in, the NCP will queue the request.  After the
current connection is terminated, RJOR will listen for and accept the
next request (in any) in its queue; if no requests are queued for it and
if it has fulfilled all of its output file requests, it will terminate
execution, releasing the main storage it occupied.  At times when RJOR
is not in core, the Logger listens on socket x'300', and will reject the
first call it receives, read RJOR into core, and dispatch it.  RJOR will
then listen on that socket.  Thus to initiate a login sequence, the user
requests connection to socket x'300'.  If accepted, he is in contact
with RJOR.  If rejected, he should reissue the connection request; when
accepted, he will be connected to RJOR.  A second rejection would
indicate that the NCP's resources were exhausted.  Once this first half
of the required duplex connection has been established, RJOR will
consider the user logged in.

バッチ・モード仕事から出力を入手するために、NetworkユーザはRJORとの全二重接続を確立しなければなりません。 単に使用中ですが(すなわち、制御情報かファイルがユーザかユーザから送られているか、またはRJORが以前に要求された出力ファイル(または、ファイル)を待っている間)、RJORはコアの居住者です。 他のすべての回、それはランダムアクセス記憶装置のときに住んでいて、Loggerを通して呼び出さなければなりません。 ソケットx'300'に接続を要求することによって、ログイン系列をいつも開始できます。 別のユーザにログインしている間、接続要求をそのソケットにすると、NCPは要求を列に並ばせるでしょう。 現在の接続が終えられた後に、RJORは待ち行列における次の要求(いずれの)を聞こうとして、受け入れるでしょう。 要求が全くそれのために列に並ばせられないで、出力ファイル要求のすべてを実現させたなら、実行を終えるでしょう、それが占領した主記憶装置をリリースして。 RJORがコアにない時代に、Loggerはソケットの上にx'300'を聴いて、それが受ける準備ラッパを拒絶して、コアからRJORを読み取って、それを派遣するでしょう。 そして、RJORはそのソケットの上に聴くでしょう。 したがって、ログイン系列を開始するために、ユーザはソケットx'300'に接続を要求します。 受け入れるなら、彼はRJORに接触しています。 拒絶されるなら、彼は接続要求を再発行するべきです。 受け入れると、彼をRJORに接続するでしょう。 2番目の拒絶は、NCPのリソースが枯渇したのを示すでしょう。 必要な重複の接続のこの前半がいったん確立されると、RJORはログインされたユーザを考えるでしょう。

     Over this first connection (hereafter called the Input Connection),
the user transmits flags designating the function(s) to be performed by
RJOR, and the name of the job to which the function(s) is(are) to be
applied.  RJOR then closes this connection.  RJOR transmits control
information specifying the disposition of the user's request and the
output file (if requested) over a secondary connection involving RJOR's
socket number x'301', site 3, and the socket at the user's site whose
socket number is one less than that on which RJOR was contacted by the
user.  The user's request may or may not be immediately executable.  If
the former is the case, RJOR issues a connection request to the
designated user receive socket, and when the connection is established
transmits whatever control information is appropriate along with the
user's output (if required); RJOR then closes the connection and the
user is considered logged out.  If the user's request cannot be

この最初の接続(今後Input Connectionと呼ばれる)の上に、ユーザは、RJOR、および機能がそうである仕事(ある)の名前によって実行されて、適用されるために(s)に機能を指定しながら、旗を送ります。 そして、RJORはこの接続を終えます。 RJORはソケット番号がRJORがユーザによって連絡されたそれよりそれほど1であるユーザのサイトで'301'という二次接続意味ありげなRJORのソケット番号xの上ユーザの要求と出力ファイル(要求されるなら)の気質を指定する制御情報、サイト3、およびソケットを送ります。 ユーザの要求はすぐに、実行可能であるかもしれません。 前者がケースであるなら、接続が要求するRJOR問題はソケットを指定ユーザに受けます、そして、接続がいつ確立されるかがどんなユーザの出力(必要なら)と共に適切な制御情報も伝えます。 次に、RJORは接続を終えます、そして、ログアウトされて、ユーザは考えられます。 ユーザの要求がそうであるはずがないなら

White                                                           [Page 5]

RFC 105                       RJE at UCSB                     March 1971

UCSB行進1971年の白い[5ページ]RFC105RJE

immediately satisfied (e.g., the job whose output is sought hasn't been
submitted yet or hasn't finished execution), the second connection is
opened by RJOR just long enough to inform the user of the delay, and
then closed.  Then when the request can be serviced, the connection is
reopened, the required data transmitted, and the connection closed; the
user is then considered logged out.

すぐに、満足していて(例えば、出力が求められる仕事は、まだ提出していないか、または実行を終えていません)、2番目の接続は、ちょうど遅れについてユーザに知らせることができるくらいの長い間RJORによって開かれて、次に、閉店します。 次に、要求を修理できるとき、接続は再開しました、そして、必要なデータは送られました、そして、接続は閉じました。 そして、ログアウトされて、ユーザは考えられます。

     To prevent RJOR from being monopolized by a single user, provision
is made within the software for terminating a connection if RJOR is ever
required to wait more than a certain amount of time for completion of a
transmission to or from the connected user.  For now, this time limit
has been set at one minute per record, but it may be shortened or
lengthened as required in the future.

RJORがシングルユーザーによって独占されているのを防ぐのに、RJORが今までにある時間よりユーザか接続ユーザからトランスミッションの完成を待たなければならないなら接続を終えるためのソフトウェアの中に備えます。 当分、このタイムリミットが1記録あたり1分に設定されていますが、それは、将来、必要に応じて短くされるか、または伸されるかもしれません。

II.B - The Input Connection

II.B--入力接続

     RJOR expects the first byte of data it receives over the Input
Connection to be zeros, indicating message Type 0; it discards this byte
unexamined, and thereafter, attaches no significance to IMP-message
boundaries.  The second byte of data received is interpreted as flags
specifying the function(s) to be performed.  Following the flag byte,
RJOR expects an eight-byte, EBCDIC job name, padded on the right with
blanks if necessary.  The flag byte is interpreted as follows:

RJORは、メッセージType0を示して、それがInput Connectionの上に受け取るデータの最初のバイトがゼロであると予想します。 それはその後非審査されたこのバイトを捨てて、大使館員はIMP-メッセージ限界への意味ではありません。 受け取られたデータの2番目のバイトは実行されるために機能を指定する旗として解釈されます。 フラグバイトに従って、RJORは、必要なら、8バイト(EBCDICジョブ名)が右で空白でそっと歩いたと予想します。 フラグバイトは以下の通り解釈されます:

     Bit 0 = 1:  transmit the output generated by the specified job.
     Bit 1 = 1:  purge the output file created by the specified job.
     Bit 2 = 1:  wait as long as is required to execute the
                 function(s) specified by Bits 0-1.
           = 0:  if the function(s) specified by Bits 0-1 cannot be
                 executed immediately, simply return an indication of
                 that fact.
     Bit 3 = 1:  an earlier request pertaining to the specified job
                 which exercised the wait-for-output (Bit 2) option
                 is to be canceled.
     Bits  4-7:  not examined, should be zeros.

ビット0 = 1: 指定された仕事で発生する出力を伝えてください。 ビット1 = 1: 指定された仕事で作成された出力ファイルを掃除してください。 ビット2 = 1: 長いときに同じくらいそのままな待ちがBits0-1によって指定された機能を実行するのが必要です。 = 0: すぐにBits0-1によって指定された機能を実行できないなら、単にその事実のしるしを返してください。 ビット3 = 1: 出力のための待ち(ビット2)オプションを運動させた指定された仕事に関係する以前の要求は取り消されることです。 ビット4-7: ゼロであるべきです調べられないで。

Any combination of Bits 0-2 is permissible.  If Bit 3 = 1, no other bits
are examined.  If Bit 0 = 1 and Bit 1 = 1, the output file is
transmitted before it is purged.  If two jobs with the same name are
executed in succession, output from the second job will overlay that
produced by the first.  In such cases, the user should purge the output
from the first job after it has been transmitted to him so that a
request for output from the second job will not simply return a second
copy of the first job's output.

Bits0-2のどんな組み合わせも許されています。 Bit3 = 1であるなら、他のビットは全く調べられません。 Bit0 = 1とBit1 = 1であるなら、それが掃除される前に出力ファイルは伝えられます。 同じ名前による2つの仕事が連続していて実行されると、副業からの出力は1日までに生産されたオーバレイを実行されるでしょう。 そのような場合、副業からの出力を求める要求が2番目のコピーの最初の仕事の出力を絶対に返さないようにそれが彼に伝えられた後にユーザは出力から最初の仕事から追放するべきです。

II.C - The Output Connection

II.C--出力接続

     RJOR may open the output connection either one or two times as the

RJORはどちらかか2回出力接続を開くかもしれません。

White                                                           [Page 6]

RFC 105                       RJE at UCSB                     March 1971

UCSB行進1971年の白い[6ページ]RFC105RJE

result of a single transmission on the Input Connection.  In each case,
the first byte transmitted will consist of zeros indicating message Type
0, and thereafter for the life of the connection, IMP-message boundaries
are not significant.  Following the first byte, RJOR will transmit the
name of the job to which the response applies.  The job name will be
contained in an 8-byte field identical to that supplied by the user over
the Input Connection.  Following the job name, RJOR will transmit zero
or more variable length logical records.  Each will consist of a one-
byte op code, a two-byte length field which specifies the unsigned
length in bits of the variable length text field which follows.  The
text field may be zero or more bytes in length; the length field will
contain an integer which is a multiple of eight.

Input Connectionにおけるただ一つのトランスミッションの結果。 その都度、伝えられた最初のバイトはメッセージType0を示すゼロから成るでしょう、そして、接続の人生には、その後、IMP-メッセージ限界は重要ではありません。 最初のバイトに続いて、RJORは応答が適用される仕事の名前を伝えるでしょう。 ジョブ名はInput Connectionの上のユーザによって供給されたそれと同じ8バイトの分野に保管されるでしょう。 ジョブ名に従って、RJORはゼロか、より可変な長さの論理レコードを伝えるでしょう。 それぞれが1バイトのオペコード(従う可変長テキストフィールドのビットの無記名の長さを指定する2バイトの長さの分野)から成るでしょう。 テキストフィールドはゼロであるかもしれませんか以上は長さはバイトです。 長さの分野は8の倍数である整数を含むでしょう。

     The op codes presently defined are listed in Figure 1.  An op code
of x'01' indicates that the text field contains one record of one of the
SYSOUT data sets created by the job whose output was requested.  The
length fields of all logical records with an op code of x'01' will be
identical.  For data sets with record lengths other than this value,
records are padded on the right side with blanks or truncated on the
right to this standard record length.  Carriage control characters which
would ordinarily appear in column 1 for printer-destined output have
been discarded and do not appear.* The records are transmitted to the
user in the same sequence as they would be printed on the printer, and
collectively include everything that would appear in printed output with
the exception of HASP separator sheets.

現在定義されているオペコードは図1に記載されています。 x'01'のオペコードは、テキストフィールドが出力が要求された仕事で作成されたSYSOUTデータセットの1つに関する1つの記録を含むのを示します。 x'01'のオペコードがあるすべての論理レコードの長さの分野は同じになるでしょう。 この値以外のレコード長があるデータセットに関しては、記録は、右側で空白で水増しされるか、またはこの標準のレコード長への右で先端を切られます。 通常、コラム1にプリンタで運命づけられた出力に関して現れるキャリッジ制御文字は、捨てられて. 彼らが同じ系列のユーザでしょうが、プリンタに印刷されて、記録が伝えられる*に見えて、HASP分離符シート以外に、出力を出版するすべてをまとめて含んでいません。

     In all logical records but those with an op code of x'01', the
length field contains the value zero, and the op code conveys the entire
meaning of the logical record.

x'01'のオペコードがあるすべての論理レコードにもかかわらず、それらでは、長さの分野は値ゼロを含んでいます、そして、オペコードは論理レコードの全体の意味を伝えます。

________________________________________________________________________
*This restriction is temporary; a fix is in the works and will be
announced.

________________________________________________________________________ *この制限は一時的です。 フィックスは、計画中であり、発表されるでしょう。

White                                                           [Page 7]

RFC 105                       RJE at UCSB                     March 1971

UCSB行進1971年の白い[7ページ]RFC105RJE

Figure 1.  Output Connection Op Codes
---------  --------------------------

図1。 出力接続オペコード--------- --------------------------

Op Code
 (Hex)    Name                   Explanation
-------   ----                   -----------

オペコード(十六進法)名前説明------- ---- -----------

  00      End-of-File.           All output from the job has been
                                 transmitted (follows last op-code-x'01'
                                 logical record).
  01      Output.                The text field contains one record of
                                 one SYSOUT data set generated by the
                                 job.
  02      Output file purged.    Output from the job has been purged as
                                 requested.
  03      No core for buffer.    Insufficient main storage is available
                                 for transmitting output from the job.
                                 The transmission request has been
                                 aborted and the purge request (if any)
                                 has been suppressed.
  04      I/O Error reading      An irrecoverable I/O error was
          file.                  encountered reading the output file.
                                 The transmission request has been
                                 aborted and the purge request (if any)
                                 suppressed.
  05      I/O Error purging      An irrecoverable I/O error was
          file.                  encountered purging the output file.
                                 The purge request was aborted.
  06      No queue space for     Output from the job was not available
          request.               and the wait-for-output option was
                                 specified, but RJOR's resources were
                                 insufficient to queue the request,
                                 which was suppressed.
  07      Waiting for output.    Output from the job is not available
                                 and the wait-for-output option was
                                 specified.  RJOR is waiting for the
                                 job's output.
  08      Canceled request not   The user requested that a previously
          found.                 made request specifying the
                                 wait-for-output option be canceled.  No
                                 such request was found by RJOR.
  09      Request canceled.      At the user's request, a previously
                                 made request specifying the
                                 wait-for-output option has been
                                 canceled.
  0A      I/O Error seeking      An irrecoverable I/O error was
          file.                  encountered attempting to locate output
                                 from the job.  The user's request was

00ファイルの終り。 仕事からのすべての出力が伝えられました(最後に演算コードx'01'論理レコードに従います)。 01 出力。 テキストフィールドは仕事で発生する1つのSYSOUTデータセットに関する1つの記録を含んでいます。 掃除された02出力ファイル。 要求された通り仕事からの出力を掃除してあります。 03 バッファのためのコアがありません。 不十分な主記憶装置は仕事から出力を伝えるのに利用可能です。 送信要求は中止されました、そして、パージ要求(もしあれば)は抑圧されました。 04の入出力のErrorの読み込みのAnの回復しがたい入出力エラーはそうでした。ファイル出力ファイルを読みながら、遭遇します。 送信要求は、中止になって抑圧されたパージ要求(もしあれば)です。 Anの回復しがたい入出力エラーを掃除した05入出力Errorはそうでした。ファイル出力ファイルを掃除しながら、遭遇します。 パージ要求は中止されました。 06 仕事からのOutputのためのどんな待ち行列スペースも利用可能な要求出力のための待ちオプションが指定されたということではありませんでしたが、RJORのリソースは、要求を列に並ばせるためには不十分でした。(要求は抑圧されました)。 07 出力を待っています。 仕事からの出力は利用可能ではありません、そして、出力のための待ちオプションは指定されました。 RJORは仕事の出力を待っています。 取り消された08は、いずれのユーザも以前に見つけられたそのaを要求しなかったよう要求します。作られていて、出力のための待ちオプションを指定して、取り消されるよう要求してください。 どんなそのような要求もRJORによって見つけられませんでした。 09要求は中止されました。 ユーザの要求によって、出力のための待ちオプションを指定する以前に人工の要求は中止されました。 Anの回復しがたい入出力エラーを求めた0A入出力Errorはそうでした。ファイル仕事からの出力の場所を見つけるのを試みながら、遭遇します。 ユーザの要求はそうでした。

White                                                           [Page 8]

RFC 105                       RJE at UCSB                     March 1971

UCSB行進1971年の白い[8ページ]RFC105RJE

                                 aborted.
  0B      Output not found.      Output from the job was not found.  The
                                 wait-for-output option was not
                                 specified by the user.

中止になる。 出力が当たらなかった0B。 仕事からの出力は見つけられませんでした。 出力のための待ちオプションはユーザによって指定されませんでした。

       [ This RFC was put into machine readable form for entry ]
         [ into the online RFC archives by Randy Dunlap 4/97 ]

[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][ランディ・ダンラップ4/97によるオンラインRFCアーカイブへの]

White                                                           [Page 9]

ホワイト[9ページ]

一覧

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

スポンサーリンク

サブクエリー SELECT文中のSELECT命令

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

上に戻る