rfc599.txt

RFC 的详细文档！

                                                               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

                            UPDATE ON NETRJS

A.  INTRODUCTION

   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"






Braden                                                          [page 1]

                                                               13 Dec 73
NIC 20854, RFC 599:  Update on NETRJS



       49,400          Cards "read"

      822,900          Lines "printed"

       18,907          Pages "printed"

        393.6          Connect hours

   The average job submitted was 360 lines ("cards"), and returned 745
   lines on 17.1 pages.  These figures are fairly typical.

B.  NEW ICP SOCKETS

   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.

C.  NEW NETRJS

   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:

      1. No More Squish

         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.






Braden                                                          [page 2]

                                                               13 Dec 73
NIC 20854, RFC 599:  Update on NETRJS



      2. Timeouts

         The new verson is a little tougher on timeouts, to free CCN
         resources when users are slow.

            a. Signon Timeout

               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.

            b. Data Transfer Timeout

               (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.

      3. New Messages

         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.

      4. Subsystem Interrupt

         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.











Braden                                                          [page 3]

                                                               13 Dec 73
NIC 20854, RFC 599:  Update on NETRJS



D.  CLARIFICATIONS AND AMENDMENTS TO NETRJS PROTOCOL

   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.

      1.  The jobname header of a print file does not have an ASA
          carriage control byte.  However, it will be encoded in the
          format (compressed or truncated) selected by a particular
          VRBT.

      2.  The punch connection sends 81 byte records, the first byte
          being a blank carriage control character.  This is contrary to
          RFC #189 and is illogical; it was an implementation bug which
          we kept for compatibility.

      3.  Page 3 of RFC #189 defined fixed values for the user's data
          transfer sockets relative to his Telnet sockets.  In fact,
          NETRJS does not enforce these user data transfer sockets but
          will accept RFC's for any user sockets.

      4.  RFC #189 specified a choice of two character mappings for the
          virtual remote batch terminal:  EBCDIC and ASCII (-68).  An
          ASCII-63 mapping was later added for the convenience of users
          with Model 33-like keyboards (RAND, actually).  The ASCII-63
          mapping is selected by doing an ICP to socket 75 or by
          entering "TTYRJS" in CN's Telnet Server.  figure 1 shows the
          actual ASCII-63 mapping in use today.  This supercedes the
          earlier version of the mapping, shown in RFC 338.

      5.  The ASCII-68 mapping specified in RFC 189 was also changed to
          provide unique mappings for all ASCII characters.  The present
          ASCII-68 mapping used by both NETRJS and TSO at CCN is shown
          in Figure 1.

E.  RJS TERMINAL OPTIONS

   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.

      1. Truncated/Compressed Data Format

         As explained in RFC 189, a virtual remote batch terminal under
         RJS may use either the turncated data format (default) or the





Braden                                                          [page 4]

                                                               13 Dec 73
NIC 20854, RFC 599:  Update on NETRJS



         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.

      2. Automatic Coldstart Job Resubmission

         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.

      3. Automatic Output RESTART

         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