<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html;
      charset=windows-1252">
  </head>
  <body>
    <p>Let me clarify this a bit.  Leaving LAT aside, Tops-10 and
      Tops-20 implement two remote terminal protocols for DECnet.  The
      Digital common one is CTERM, which runs on all (or most)
      platforms.  Unfortunately, there are some minor problems with the
      current Tops-20 CTERM implementation that are annoying.  For
      example, you can't use space as an un-pause character, which I've
      been doing since about 1978.  Fixing it (if possible) means I've
      got to wade into the monitor and that could mean months before I
      come back up for air.</p>
    <p>I remembered a previous remote terminal protocol (NRT) that I
      think was available in either late Phase II or Phase III, but only
      between 20's (and eventually 10's).  It is in no way as rich as
      CTERM (the difference perhaps being reminiscent of that between
      FTP and DAP), but it is far less complex.  It appears to have been
      modeled in some ways along the lines of the Tops-20 ARPA NCP NVT
      (without the IAC negotiations).  The interface is close enough so
      that the Tops-20 TELNET program can use it.</p>
    <p>However, the Tops-20 NRT CLIENT (SETHOST) appears to have been
      effectively abandoned in favor of the CTERM client and this is
      understandable, given that CTERM was the common platform and
      corporate direction.  That it is unfortunate as NRT is more
      efficient.  Most importantly, NRT doesn't have the above
      annoyances.   But SETHOST needed further productization.  Like
      FAL/DAP, bugs hurtled out of it as I started using it.  MRC had
      modified it to assume a 2020 (I.E., Tops-20 4.2) which denied
      other efficiencies.  Right now, I've got about eight fixes and
      enhancements in.  It's quite tolerable.<br>
    </p>
    <div class="moz-cite-prefix">The other reason for dusting off NRT is
      that would allow run FAL with the proper credentials as the
      top-level fork of a separate job.  Right now, it runs privileged,
      (either SC%WHL or SC%OPR on Tops-20 or JACCT or [1,2] on
      Tops-10.   Although checking is done, this is still A Bad Idea. 
      The FTP server, for example runs as a top-level fork.  The changes
      to the Tops-20 NRT server are very small to allow me to do the
      same thing with FAL.</div>
    <div class="moz-cite-prefix">
      <p>If other DECnet based operating systems support NRT, then I
        would like to know about that.  Right now, the client checks the
        remote OS and won't connect if it isn't Tops-10 or Tops-20.<br>
      </p>
    </div>
    <blockquote type="cite"
      cite="mid:0bb3dd70-a7c6-343c-15e1-8eaa342d2112@softjar.se">
      <hr width="100%" size="2">On 5/4/20 7:24 PM, Johnny Billquist
      wrote:<br>
      <br>
      Implementing where? I thought TOPS-20 as well as Tops-10 already
      had it. It's even on the RSX distribution...
      <br>
      <blockquote type="cite">
        <hr width="100%" size="2">On 2020-05-05 00:29, Thomas DeBellis
        wrote:
        <br>
        <br>
        Right now, I'm working on SETHOST, which is a client for the
        earlier NRT protocol (Network Remote Terminal) that predates
        CTERM on the 36 bit platform.  It's more efficient than CTERM (I
        have yet to compare it with LAT) and will do certain things that
        I like that the Tops-20 implementation of CTERM doesn't.
        <br>
      </blockquote>
    </blockquote>
  </body>
</html>