File: rfc105.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (507 lines) | stat: -rw-r--r-- 21,938 bytes parent folder | download | duplicates (5)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507






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

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


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

I - Remote Job Entry (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.

     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.

I.A - Logging into 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



White                                                           [Page 1]

RFC 105                       RJE at UCSB                     March 1971


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.

     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.

I.B - The RJE Connection

     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:

     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.

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



White                                                           [Page 2]

RFC 105                       RJE at UCSB                     March 1971


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:

        /*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.

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

    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:

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

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

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



White                                                           [Page 3]

RFC 105                       RJE at UCSB                     March 1971


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:

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

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

     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:

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

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)

     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.



White                                                           [Page 4]

RFC 105                       RJE at UCSB                     March 1971


     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.

II.A - Logging into 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.

     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



White                                                           [Page 5]

RFC 105                       RJE at UCSB                     March 1971


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.

     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.

II.B - The Input Connection

     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:

     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.

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.

II.C - The Output Connection

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



White                                                           [Page 6]

RFC 105                       RJE at UCSB                     March 1971


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.

     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.

     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.
















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



White                                                           [Page 7]

RFC 105                       RJE at UCSB                     March 1971


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

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



White                                                           [Page 8]

RFC 105                       RJE at UCSB                     March 1971


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

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












































White                                                           [Page 9]