As per Relevance of the word terminal, we have this rfc below:
RFC 740 RTB 42423 22 Nov 77
NETRJS
Network Working Group R.
Request for Comments: 740 UCLA-
NIC: 42423 22 November 1977
Obsoletes: 189, 599
NETRJS
A.
NETRJS, a private protocol for remote job entry service, was
and implemented by the UCLA Campus Computing Network (CCN) for
job submission to an IBM 360 Model 91. CCN's NETRJS server allows
remote user, or a daemon process working in behalf of a user,
access CCN's RJS ("Remote Job Service") subsystem. RJS
remote job entry service to real remote batch (card reader/
printer) terminals over direct communications lines as well as to
ARPANET
A batch user at a remote host needs a NETRJS user process
communicate with the NETRJS server at the batch host. An
NETRJS user process simulates a "Virtual Remote Batch Terminal",
"VRBT".
A VRBT may have virtual card readers, printers, and punches.
addition, every VRBT has a virtual remote operator console. Using
virtual card reader, a Network user can transmit a stream of
images comprising one or more batch jobs, complete with job
language ("JCL"), to the batch server host. The NETRJS server
cause these jobs to be spooled into the batch system to be
according to their priority. NETRJS will automatically return
print and/or punch output images which are created by these jobs
the virtual printer and/or card punch at the VRBT from which the
was submitted. The batch user can wait for his output, or he
signoff and signon again later to receive it
To initiate a NETRJS session, the user process must execute
standard ICP to a fixed socket at the server. The result is
establish a full-duplex Telnet connection for the virtual
operator console, allowing the VRBT to signon to RJS. The
remote operator console can then be used to issue commands to
and to receive status, confirmation, and error messages from
Braden [page 1]
RFC 740 RTB 42423 22 Nov 77
NETRJS
server. The most important remote operator commands are
in Appendix D
Different VRBT's are distinguished by 8-character terminal id's
which are assigned by the server site to individual batch users
user groups
B. Connections and
The protocol uses up to five connections between the user and
processes. The operator console uses a a full-duplex
connection. The data transfer streams for the virtual card reader
printer, and punch each use a separate simplex connection under
data transfer protocol defined in Appendix A. This document will
the term "channel" for one of these simplex data transfer
and will designate a connection "input" or "output" with reference
the server
A particular data transfer channel needs to be open only while it
in use, and different channels may be used sequentially
simultaneously. CCN's NETRJS server will support
operation of a virtual card reader, a virtual printer, and a
punch (in addition to the operator console) on the same VRBT process
The NETRJS protocol could easily be extended to any number
simultaneously-operating virtual card readers, printers, and punches
The NETRJS server takes a passive role in opening the data channels
the server only "listens" for an RFC from the user process. NETRJS
defined with an 8-bit byte size on all data channels
Some implementations of NETRJS user processes are daemons,
as background processes to submit jobs from a list of user requests
other implementations are interactive processes executed
under terminal control by remote users. In the latter case, the
process generally multiplexes the user terminal between NETRJS, i.e.,
acting as the remote operator console, and entering local commands
control the VRBT. Local VRBT commands allow selection of the
containing job streams to be sent to the server as well as files
receive job output from the server. Other local commands would
the VRBT to open data transfer channels to the NETRJS server and
close these channels to free buffer space or abort transmission
The user process has a choice of three ICP sockets, to select
character set of the VRBT -- ASCII-68, ASCII-63, or EBCDIC.
server will make the corresponding translation of the data in
card reader and printer channels. (In the CCN implementation
NETRJS, an EBCDIC VRBT will transmit and receive,
Braden [page 2]
RFC 740 RTB 42423 22 Nov 77
NETRJS
translation, "transparent" streams of 8-bit bytes, since CCN is
EBCDIC installation). The punch stream will always be transparent
outputting "binary decks" of 80-byte records untranslated.
operator console connections always use Network ASCII, as defined
the Telnet protocol
The NETRJS protocol provides data compression, replacing
blanks or other characters by repeat counts. However, when
terminal id is assigned, a particular network VRBT may be
to use no data compression. In this case, NETRJS will
truncate trailing blanks and send records in a simple "
code-length-data" form, called "truncated format" (see Appendix A).
C. Starting and Terminating a
The remote user establishes a connection to the NETRJS server
executing an ICP to the contact socket 71 (decimal) for EBCDIC
socket 73 (decimal) for ASCII-68, or to socket 75 (decimal)
ASCII-63. A successful ICP results in a pair of connections which
in fact the NETRJS operator console connections. NETRJS will send
READY message over the operator output connection
The user (process) must now enter a valid NETRJS signon
("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
refusal by closing both operator connections. If the user fails
enter a valid signon within 3 minutes, NETRJS will close the
connections. If the VRBT attempts to open data transfer
before the signon command is accepted, the data transfer
will be refused with an error message to the VRBT operator console
Suppose that S is the even number sent in the ICP; then the
connections have sockets at the server with fixed relation to S,
shown in the following table
Channel Server Socket User
------- ------------- -----------
Remote Operator Console Input S U + 3
Remote Operator Console Output S + 1 U + 2
Data Transfer - Card Reader #1 S + 2 any odd
Data Transfer - Printer #1 S + 3 any even
Data Transfer - Punch #1 S + 5 any even
Once the VRBT has issued a valid signon, it can open data
channels and initiate input and output operations as explained in
following sections. To terminate the session, the VRBT may close
Braden [page 3]
RFC 740 RTB 42423 22 Nov 77
NETRJS
connections. Alternatively, it may enter a SIGNOFF command
the virtual remote operator console. Receiving a SIGNOFF,
will wait until the current job output streams are complete and
itself terminate the session by closing all connections
D. Input
A job stream for submission to the NETRJS server is a series
logical records, each of which is a card image of at most 80
characters. The user can submit a "stack" of successive jobs
the card reader channel with no end-of-job indication between jobs
NETRJS is able to parse the JCL sufficiently to recognize
beginning of each job
To submit a batch job or stack of jobs for execution, the
process must first open the card reader channel by issuing an
for foreign socket S+2 and the appropriate local socket. NETRJS
which is listening on socket S+2, will return an RTS command to
the channel. When the channel is open, the user can begin sending
job stream using the protocol defined in Apendix A. For each
successfully spooled, NETRJS will send a confirming message to
remote operator console
At the end of the job stack, the user process must send
End-of-Data transaction to initiate processing of the last job
NETRJS will then close the channel (to avoid holding buffer
unnecessarily). At any time during the session, the user process
re-open the card reader channel and transmit another job stack.
can also terminate the session and signon later to get the output
If the user process leaves the channel open for 5 minutes
sending any bits, the server will abort (close) the channel. The
process can abort the card reader channel at any time by closing
channel; NETRJS will then discard the last partially spooled job
If NETRJS finds an error (e.g., transaction sequence number error
a dropped bit), it will abort the channel by closing the
prematurely, and also inform the user process that the job
discarded (thus solving the race condition between End-of-Data
aborting). The user process should retransmit only those jobs in
stack that have not been completely spooled
If the user's process, NCP, or host, or the Network itself
during input, RJS will discard the job being transmitted. A
informing the user that this job was discarded will be generated
sent to him the next time he signs on. On the other hand, those
whose receipt have been acknowledged on the operator's console
not be affected by the failure, but will be executed by the server
Braden [page 4]
RFC 740 RTB 42423 22 Nov 77
NETRJS
E. Output
The VRBT may wait to set up a virtual printer or punch and open
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
also control which one of several available jobs is to be returned
entering appropriate operator commands
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
punch output, respectively. NETRJS is listening on these sockets
should immediately return an STR. However, it is possible
because of a buffer shortage, NETRJS will refuse the connection
returning a CLS; in this case, try again later
When NETRJS has job output for a particular virtual terminal and
corresponding open output channel, it will send the output as
series of logical records using the protocol in Appendix A.
first record will consist of the job name (8 characters) followed
a comma and then the ID string from the JOB card, if any. In
printer stream, the first column of each record after the first
be an ASA carriage control character (see Appendix C). A
printer in NETRJS has 254 columns, exclusive of carriage control
NETRJS will send up to 255 characters of a logical record it finds
a SYSOUT data set. If the user wishes to reject or fold
longer than some smaller record size, he can do so in his
process
NETRJS will send an End-of-Data transaction and then close an
channel at the end of the output for each complete batch job;
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
job without breaking the output within a job
If the batch user wants to cancel (or backspace or defer) the
of a particular job, he can enter appropriate NETRJS commands on
operator input channel (see Appendix D).
If NETRJS encounters a permanent I/O error in reading the disk
set, it will notify the user via his console, skip forward to
next set of system messages or SYSOUT data set in the same job,
continue. If the user process stops accepting bits for 5 minutes,
server will abort the channel. In any case, the user will
notification of termination of output data transfer for each job
a remote console message
Braden [page 5]
RFC 740 RTB 42423 22 Nov 77
NETRJS
If the user detects an error in the stream, he can issue a
(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
the beginning of the job, or he can abort the channel by closing
socket. If he aborts the channel, NETRJS will simulate a
command, and when the user re-opens the channel the job will
transmission again from an earlier point in the same data set.
is true even if the user terminates the current session first
reopens the channnel in a later session; RJS saves the state of
incomplete output stream. However, before re-opening the channel
can defer this job for later output, restart it at the beginning,
cancel its output (see Appendix D). Note that aborting the
is only effective if NETRJS has not yet sent the End-of-
transaction
If the user's process, NCP, or host or the Network itself
during an output operation, NETRJS will act as if the channel
been aborted and the user signed off. NETRJS will discard the
of a job only after receiving the RFNM from the last data
message (containing an End-of-Data). In no case should a NETRJS
lose output from a batch job
Braden [page 6]
RFC 740 RTB 42423 22 Nov 77
NETRJS
APPENDIX
Data Transfer Protocol in
1.
The records in the data transfer channels (for virtual
reader, printer, and punch) are generally grouped
transactions preceded by headers. The transaction header
a sequence number and the length of the transaction. Network
size must be 8 bits in these data streams
A transaction is the unit of buffering within the server software
and is limited to 880 8-bit bytes. Transactions can be as short
one record; however, those sites which are concerned
efficiency should send transactions as close as possible to
880 byte limit
There is no necessary connection between physical
boundaries and transactions ("logical messages"); the NCP
break a transaction arbitrarily into physical messages. The
server starts each transaction at the beginning of a new
message, but this is not a requirement of the protocol
Each logical record within a transaction begins with an "op code
byte which contains the channel identification, so its value
unique to each channel but constant within a channel. This
provides the receiver with a convenient way to
bit-synchronization, and it also allows an extension in the
to true "multi-leaving" (i.e., multiplexing all channels
one connection in each direction).
The only provisions for transmission error detection in
current NETRJS protocol are (1) the "op code" byte to verify
synchronization and (2) the transaction sequence number. Under
NETRJS protocol, a data transfer error must abort the
transmission; there is no provision for restart
Braden [page 7]
RFC 740 RTB 42423 22 Nov 77
NETRJS
2. Meta-
The following description of the NETRJS data transfer
uses a formal notation derived from that proposed in RFC 31
Bobrow and Sutherland. The notation consists of a series
productions for bit string variables. Each variable name
represents a fixed length field is followed by the length in
(e.g., SEQNUMB(16)). Numbers enclosed in quotes are decimal
unless qualified by a leading X meaning hex. Since each hex
is 4 bits, the length is not shown explicitly in hex numbers.
example, '255'(8) and X'FF' both represent a string of 8 one bits
The meta-syntactic operators are
| :alternative
[ ] :optional
( ) :
+ :catenation of bit
The numerical value of a bit string (interpreted as an integer)
symbolized by a lower case identifier preceding the
expression and separated by a colon. For example,
"i:FIELD(8)", i symbolizes the numeric value of the 8 bit
FIELD
Finally, we use Bobrow and Sutherland's symbolism for iteration
a sub-string: (STRING-EXPRESSION = n); denotes n occurrences
STRING-EXPRESSION, implicitly catenated together. Here any
greater or equal to 0 is assumed unless n is
restricted
3. Protocol
STREAM ::= (TRANSACTION = n) + [END-OF-DATA
That is, STREAM, the entire sequence of data on a
open channel, is a sequence of n TRANSACTIONS followed by
END-OF-DATA marker (omitted if the sender aborts the channel).
TRANSACTION ::= 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
Braden [page 8]
RFC 740 RTB 42423 22 Nov 77
NETRJS
THEAD ::= X'FF'+f:FILLER(8)+SEQNUMB(16)+LENGTH(32)+X'00'
Transactions are to be consecutively numbered in the
field, starting with 0 in the first transaction after
channel is (re-) opened. The 32 bit LENGTH field gives
total length in bits of the r RECORD's which follow.
convenience, the using site may add f additional filler bits
the end of the transaction to reach a convenient word
on his machine; the value f is transmitted in the FILLER
of THEAD
RECORD ::= COMPRESSED |
RJS will accept intermixed RECORD's which are COMPRESSED
TRUNCATED in an input stream. RJS will send one or the
format in the printer and punch streams to a given VRBT;
choice is determined for each terminal id
COMPRESSED ::= '2'(2) + DEVID(6) + (STRING = p) + '0'(8)
STRING ::= ('6'(3) + i:DUPCOUNT(5)) |
This form represents a string of i consecutive
('7'(3) + i:DUPCOUNT(5) + TEXTBYTE(8)) |
This form represents string of i consecutive duplicates
TEXTBYTE
('2'(2) + j:LENGTH(6) + (TEXTBYTE(8) = j))
This form represents a string of j characters
TRUNCATED ::= '3'(2) + DEVID(6) + n:COUNT(8) + (TEXTBYTE(8)=n
DEVID(6) ::= DEVNO(3) + t:DEVTYPE(3)
DEVID identifies a particular virtual device, i.e.,
identifies a channel. DEVTYPE specifies the type of device,
follows
t = 1: Output to remote operator
2: Input from remote operator
3: Input from card
4: Output to
5: Output to card
6,7:
Braden [page 9]
RFC 740 RTB 42423 22 Nov 77
NETRJS
DEVNO identifies the particular device of type t at this
site; at present only DEVNO = 0 is possible
END-OF-DATA ::=X'FE
Signals end of job (output) or job stack (input).
Braden [page 10]
RFC 740 RTB 42423 22 Nov 77
NETRJS
APPENDIX
Telnet for VRBT Operator
The remote operator console connections use the ASCII
protocol. Specifically
1. The following one-to-one character mappings are used for
three EBCDIC graphics not in ASCII
ASCII in Telnet |
----------------------------------------------------
broken vertical bar | solid vertical
tilde | not
back slash | cent
2. Telnet controls are ignored
3. An operator console input line which exceeds 133
(exclusive of CR LF) is truncated by NETRJS
4. NETRJS accepts BS (Control-H) to delete a character and
(Control-X) to delete the current line. The sequence CR
terminates each input and output line. HT (Control-I)
translated to a single space. An ETX (Control-C)
(aborts) the session. All other ASCII control characters
ignored
5. NETRJS translates the six ASCII graphics with no equivalent
EBCDIC into the character question mark ("?") on input
Braden [page 11]
RFC 740 RTB 42423 22 Nov 77
NETRJS
APPENDIX
Carriage
The carriage control characters sent in a printer channel by
conform to IBM's extended USASI code, defined by the following table
CODE ACTION BEFORE WRITING
---- ----------------------------
Blank Space one line before
0 Space two lines before
- Space three lines before
+ Suppress space before
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
Braden [page 12]
RFC 740 RTB 42423 22 Nov 77
NETRJS
APPENDIX
Network/RJS Command
This section presents an overview of the RJS Operator Commands,
the complete form and parameter specifications please see
2 and 3.
Terminal Control and Information
SIGNON First command of a session; identifies VRBT by
its terminal id
SIGNOFF Last command of a session; RJS waits for any
transfer in progress to complete and then closes
connections
STATUS Outputs on the remote operator console a
list, or a summary, of all jobs in the system
this VRBT, with an indication of their
status in the batch host
ALERT Outputs on the remote operator console an "Alert
message, if any, from the computer operator.
Alert message is also automatically sent when
user does a SIGNON, or whenever the message changes
MSG Sends a message to the computer operator or to
other RJS terminal (real or virtual). A message
the computer operator or another RJS terminal
automatically appear on the remote operator console
Job Control and Routing
Under CCN's job management system, the default destination
output is the input source. Thus, a job submitted under a
VRBT will be returned to that VRBT (i.e., the same terminal id),
unless the user's JCL overrides the default destination
RJS places print and punch output destined for a particular
terminal into either an Active Queue or a Deferred Queue.
the user opens his print or punch output channel, RJS
starts sending job output from the Active Queue, and
until this queue is empty. Job output in the Deferred Queue,
the other hand, must be called for by job name, (via a
command from the remote operator) before RJS will send it.
Active/Deferred choice for output from a job is determined by
Braden [page 13]
RFC 740 RTB 42423 22 Nov 77
NETRJS
deferral status of the VRBT when the job is entered; the
status, which is set to the Active option when the user signs on
may be changed by the SET command
SET Allows the remote user to change certain
of his VRBT for the duration of the current session
(a) May change the default output destination to
another (real or virtual) RJS terminal or
central facility
(b) May change the deferral status of the VRBT
DEFER Moves the print and punch output for a specified
or set of jobs from the Active Queue to the
Queue. If the job's output is in the process
being transmitted over a channel, RJS aborts
channel and saves the current output location
moving the job to the Deferred Queue. A
RESET command will return it to the Active
with an implied Backspace (BSP).
RESET Moves specified job(s) from Deferred to Active
so they may be sent to user. A specific list of
names or all jobs can be moved with one
command
ROUTE Re-routes output of specified jobs (or all jobs
waiting in the Active and Deferred Queues for
VRBT. The new destination may be any other
terminal or the central facility
ABORT Cancels a job which was successfully submitted
awaiting execution or is currently executing
Output Stream Control
BSP (BACKSPACE) "Backspaces" output stream within current
data set. Actual amount backspaced depends
sysout blocking but is roughly equivalent to a
on the line printer
CAN (CANCEL) (a) On an output channel, CAN causes the rest
the output in the sysout data set currently
transmitted to be omitted. Alternatively, may
the rest of the sysout data sets for the
currently being transmitted; however, the
Braden [page 14]
RFC 740 RTB 42423 22 Nov 77
NETRJS
system and accounting messages will be sent
(b) On an input channel, CAN causes RJS to
the job currently being read. However, the
is not aborted as a result, and RJS will
reading in jobs on the channel
(c) CAN can delete all sysout data sets
specified job(s) waiting in Active or
Queue
RST (RESTART) (a) Restarts a specified output stream at
beginning of the current sysout data set or
optionally, at the beginning of the job
(b) Marks as restarted specified job(s)
transmission was earlier interrupted by
failure or user action (e.g., DEFER command
aborting the channel). When RJS transmits
jobs again it will start at the beginning of
partially transmitted sysout data set or
optionally, at the beginning of the job.
function may be applied to jobs in either the
or the Deferred Queue; however, if the job was
the Deferred Queue then RST also moves it to
Active Queue. If the job was never transmitted,
has no effect other than this queue movement
REPEAT Sends additional copies of the output of
jobs
EAM Echoes the card reader stream back in the
and/or punch stream
Braden [page 15]
RFC 740 RTB 42423 22 Nov 77
NETRJS
APPENDIX
NETRJS TERMINAL
When a new NETRJS virtual terminal is defined, certain options
available; these options are listed below
1. Truncated/Compressed Data
A VRBT may use either the truncated data format (default)
the compressed format for printer and punch output.
Reference 9 for discussion of the virtues of compression
2. Automatic Coldstart Job
If "R" (Restart) is specified in the accounting field on
JOB card and if this option is chosen, RJS will
resubmit the job from the beginning if the server
system should be "coldstarted" before all output from the
is returned. Otherwise, the job will be lost and must
resubmitted from the remote terminal in case of a coldstart
3. Automatic Output
With this option, transmission of printer output which
interrupted by a broken connection always starts over at
beginning. Without this option, the output is
approximately one page when restarted, unless the user
the output to start over from the beginning with a
command when the printer channel is re-opened and
printing begins
4. Password
This option allows a password to be supplied when a terminal
signed on, preventing unauthorized use of the terminal ID
5. Suppression of Punch Separator and Large Letters
This option suppresses both separator cards which RJS
puts in front of each punched output deck, and separator
on printed output containing the job name in large
letters. These separators are an operational aid when
ouptut is directed to a real printer or punch, but
undesirable for an ARPA user who is saving the output in a
for on-line examination
Braden [page 16]
RFC 740 RTB 42423 22 Nov 77
NETRJS
APPENDIX
Character Translation by CCN
A VRBT declares its character set for job input and output by
initial connection socket it chooses. A VRBT can have the ASCII-68,
the ASCII-63, or the EBCDIC character set. The ASCII-63
mapping was added to NETRJS at the request of users whose
are equipped with keyboards like those found on the model 33
Teletype
Since CCN operates an EBCDIC machine, its NETRJS server
ASCII input to EBCDIC and translates printer output back to ASCII
The details of this translation are described in the following
For ASCII-68, the following rules are used
1. There is one-to-one mapping between the three ASCII
broken vertical bar, tilde, and back slash, which are not
EBCDIC, and the three EBCDIC characters vertical bar,
sign, and cent sign (respectively), which are not in ASCII
2. The other six ASCII graphics not in EBCDIC are translated
input to unused EBCDIC codes, shown in the table below
3. The ASCII control DC4 is mapped to and from the EBCDIC
TM
4. The other EBCDIC characters not in ASCII are mapped in
printer stream into the ASCII question mark
For ASCII-63, the same rules are used except that the ASCII-63
X'60' and X'7B' - X'7E' are mapped as in the following table
EBCDIC | ASCII-68 VRBT | ASCII-63
---------------------------------------------------------------
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'
Braden [page 17]
RFC 740 RTB 42423 22 Nov 77
NETRJS
APPENDIX
1. "Interim NETRJS Specifications", R. T. Braden. RFC #189:
#7133, July 15, 1971.
This was the basic system programmer's definition document.
proposed changes mentioned on the first page of RFC #189
never implemented, since the DTP then in vogue became obsolete
2. "NETRJS Remote Operator Commands", R. T. Braden. NIC #7182,
August 9, 1971
This document together with References 3 and 8 define the
operator (i.e. user) command language for NETRJS, and form
basic user documentation for NETRJS at CCN
3. "Implementation of a Remote Job Service", V. Martin and T. W
Springer. NIC #7183, July, 1971.
4. "Remote Job Entry to CCN via UCLA Sigma 7; A scenario", UCLA/CCN
NIC #7748, November 15, 1971.
This document described the first NETRJS user
available on a server host. This program is no longer of
interest
5. "Using Network Remote Job Entry", E. F. Harslem. RFC #307:
#9258, February 24, 1972.
This document is out of date, but describes generally the
NETRJS user process "RJS".
6. "EBCDIC/ASCII Mapping for Network RJS", R. T. Braden. RFC #338:
NIC #9931, May 17, 1972.
The ASCII-63 mapping described here is no longer correct,
CCN's standard ASCII-68/EBCDIC mapping is described correctly
This information is accurately described in Appendix F of
current document
Braden [page 18]
RFC 740 RTB 42423 22 Nov 77
NETRJS
7. "NETRJT--Remote Job Service Protocol for TIP's", R. T. Braden.
#283: NIC 38165, December 20, 1971.
This was an attempt to define an rje protocol to handle TIPs
Although NETRJT was never implemented, many of its features
incorporated in the current Network standard RJE protocol
8. "CCN NETRJS Server Messages to Remote User", R. T. Braden.
#20268, November 26, 1973.
9. "FTP Data Compression", R. T. Braden. RFC #468: NIC #14742,
March 8, 1973.
10. "Update on NETRJS", R. T. Braden. RFC #599: NIC #20854,
13, 1973.
This updated reference 1, the current document combines the two
11. "Network Remote Job Entry -- NETRJS", G. Hicks. RFC #325:
9632, April 6, 1972.
12. "CCNRJS: Remote Job Entry between Tenex and UCLA-CCN", D
Crocker. NUTS Note 22, [ISI]<DOCUMENTATION>CCNRJS.DOC, March 5,
1975.
13. "Remote Job Service at UCSB", M. Krilanovich. RFC #477:
#14992, May 23, 1973.
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX