13 Dec 73 NIC 20854, RFC 599: Update on NETRJS Network Working Group Robert T. Braden NIC #20854 UCLA/CCN RFC #599 December 13, 1973
In July 1971, CCN published RFC #189 defining NETRJS, a private protocol for remote job entry. NETRJS provides a Network interface to CCN's rje program called RJS (Remote Job Service).(3) As noted in an earlier RFC,(6) "RJS" is the proper name of a software package existing ony at CCN, not a generic term for rje.
For over two years now, CCN has provided rje service to the Network using NETRJS. We know of the following distinct implementations of NETRJS user porgrams:
RAND OS/MVT on 370/158 (originally on 360/65) UCLA-NMC SEX on Sigma 7 Illinois ANTS on PDP-11 Utah Tenex on PDP-10 MIT-DMCG ITS on PDP-10 Harvard DEC system on PDP-10 UCSB OS/MVT on 360/75 ISI,BBN,NIC,I4 Tenex on PDP-10
We apologize to anyone slighted by omission from this list. Writing a new user process for NETRJS has proved to be a modest and straightforward task.
During the month of October, 1973, CCN processed 1373 batch jobs via NETRJS. The complete statistics are:
1,373 Jobs submitted 1,105 Jobs "printed" 0 Jobs "punched"
13 Dec 73
49,400 Cards "read" 822,900 Lines "printed" 18,907 Pages "printed"
The average job submitted was 360 lines ("cards"), and returned 745 lines on 17.1 pages. These figures are fairly typical.
At the request of the Socket Czar, Jon Postel, (see RFC #433) we intend to move the NETRJS ICP sockets from 11, 13, and 15 to 71, 73, and 75, respectively. At present, NETRJS is available from either socket subspace, so system programmers responsible for maintaining NETRJS user processes can switch over at their leisure. We plan to "decommit" sockets 11, 13, and 15 on July 1, 1974.
Those hosts which access NETRJS via socket 1 are unaffected.
Last Fall, CCN installed a new implementation of its NETRJS server. An internal NETRJS rewrite was necessitated by other system changes and was timed to coincide with installation on September 5 of the "last release" of OS/360, Release 21.7. The new version of NETRJS contains a number of internal improvements over the original version written two years ago. There are also a few external differences, as follows:
The long-standing "squish" problem in NETRJS has been fixed. This problem arose because of the "squishiness" of Network data transfer, i.e. the variable delay between originator and receiver processes due to NCP buffering. The result was that a short print output file could be "transmitted" by RJS, dequeued, and discarded at CCN before the first message had actually reached the remote host. If the remote host crashed or the user tried to cancel (and save) the output stream, it was too late; the output was lost in the "squish". We were careless about this in the first version. Now NETRJS awaits the RFNM from the end-of-data mark before telling RJS to discard the job output.
13 Dec 73
The new verson is a little tougher on timeouts, to free CCN resources when users are slow.
If the user, after connecting to NETRJS and receiving the READY message, fails to send a valid SIGNON command within 3 minutes, CCN will close the Telnet connections.
(1) CCN will abort the READER data transfer connection if the user site leaves the connection open without sending any bits for 5 minutes.
(2) CCN will abort the PRINTER or PUNCH data transfer connection if the user site stops accepting bits for 5 minutes.
The NETRJS messages to the remote terminal have been revised to better distinguish problems at CCN, at the user site, or in the Network. See Reference 8 for a complete list.
The user can send a Control-C to terminate his NETRJS session either before or after signon. Continuation is not possible after the Control-C.
This provides an escape for a user who for some reason can't signon or signoff or close his Telnet connection. If the user entered via the RJS command in Socket 1, Control C will return him to the Server Telnet command level.
One other improvement will reduce user frustration: NETRJS now returns an INVALID SIGNON message if the user enters anything but a valid SIGNON command after initially connecting to the NETRJS server.
13 Dec 73
Over the past two years, system programmers writing NETRJS user processes have pointed out areas of the protocol which were poorly defined in RFC #189. In addition a few minor changes have been made, largely as the result of implementation accidents.
When a new NETRJS virtual terminal is defined, certain options are available; these options are listed below. If the user does not specify otherwise, CCN will use truncated data format and turn all other options on.
As explained in RFC 189, a virtual remote batch terminal under RJS may use either the turncated data format (default) or the
13 Dec 73
compressed format for printer and punch output. With the truncated format, CCN merely removes trailing blanks from each output line; if compressed format is specified, CCN will also encode strings of inbedded blanks or other repeated characters. CCN will accept either format in the card reader stream, regardless of the terminal option. See Reference 9 for discussion of the virtues of compression.
If "R" (Restart) is specified in the accounting field on the JOB card and if this option is chosen, RJS will automatically resubmit the job from the beginning if the CCN operating system should be "coldstarted" before all output from the job is returned. Otherwise, the job will be lost and must be resubmitted from the remote terminal in case of a coldstart.
With this option, transmission of printer output which is interrupted by a broken connection always starts over at the beginning. Without this option, the output is backspaced approximately one page when restarted, unless the user forces the output to start over from the beginning with a RESTART command when the printer connection is re-opened and before printing begins.
This option allows a password to be supplied when a terminal is signed on, preventing unauthorized use of the terminal ID.
This option suppresses both separator cards which RJS normally puts in front of each punched output deck, and separator pages on printed output containing the job name in large block letters. These separators are an operational aid when the ouptut is directed to a real printer or punch, but generally undesirable for an ARPA user who is saving the output in a file for on-line examination.
13 Dec 73
The Tenex implementation of NETRJS user program is a command normally called "RJS". This program has some pitfalls of which users should be aware.
This is the basic system programmer's definition document, and is really the final specification. The proposed changes mentioned on the first page of RFC #189 were never implemented, since the DTP then in vogue became obsolete.
This document together with References 3 and 8 define the remote operator (i.e. user) command language for NETRJS, and form the basic user documentation for NETRJS at CCN.
This document described the first NETRJS user implementation available on a server host. This program is no longer of general interest.
13 Dec 73
This document is out of date, but describes generally the Tenex NETRJS user process "RJS".
The ASCII-63 mapping described here is no longer correct, but CCN's standard ASCII-68/EBCDIC mapping is described correctly.
This was an attempt to define an rje protocol to handle TIPs. Although NETRJT was never implemented, many of its features are incorporated in the current Network standard RJE protocol.
13 Dec 73
The character set of the VRBT (VIRTUAL Remote Batch Terminal) is determined by the initial connection to RJS, as follows:
VRBT Character Set | ICP Socket OR Server Telnet Command ---------------------------------------------------------------- EBCDIC | 71 | RJS ASCII-68 | 73 | ARJS ASCII-63(tty) | 75 | TTYRJS
These mappings are as follows:
ASCII-68 Mapping:
Corresponding graphics are mapped one-to-one.
Unmatched graphics are mapped as in the table below.
ASCII-68 controls are mapped one-to-one onto the matching EBCDIC controls, with DC4(ASCII) mapped onto TM(EBCDIC).
ASCII-63 Mapping:
Corresponding graphics are mapped one-to-one.
ASCII codes X'61' - X'7A' (the ASCII-68 lower case letters are mapped onto EBCDIC lower case.
Unmatched graphics are mapped as shown in the table below.
ASCII-63 controls X'00' - X'1F' are mapped as for ASCII-68.
ASCII codes X'60' and X'7B' - X'7E' are mapped as shown in the following table.
13 Dec 73
EBCDIC | ASCII-68 VRBT | ASCII-63 VRBT --------------------------------------------------------------- vertical bar X'4F' | vertical bar X'7C' | open bracket X'5B' not sign X'5F' | tilde X'7E' | close bracket X'5D' cent sign X'4A' | back slash X'5C' | back slash X'5C' underscore X'6D' | underscore X'5F' | left arrow X'5F' . X'71' | up arrow X'5E' | up arrow X'5E' open bracket X'AD' | open bracket X'5B' | . X'7C' close bracket X'BD' | close bracket X'5D' | . X'7E' . X'8B' | open brace X'7B' | . X'7B' . X'9B' | close brace X'7D' | . X'7D' . X'79' | accent X'60' | . X'60'
Note : this page is available on-line as HELP RJSCHARS in CCN's Telnet Server (Socket 1). The on-line version is set up to be typed out on an ASCII-68 terminal.