Updating the Tops-20 Finger client was simple enough, a table entry for DECnet and a small routine to build the JFN string, viz:

FINGER>@mim
[Fork FINGER opening DCN:MIM-117 for reading, writing]
 18:40:07 FINGER IO wait at FNGPRT+23  Used 0:00:09.5 in 481:11:26, Load   0.04
RSX-11M-PLUS system MIM. Tue Jun 18 00:40:08 2024. Up: 2 days, 22:09.

                                                                     Luser          Real name                 Term    Idle Logged in
                                                                                                                                    B
ILLQUIST      Johnny Billquist          TT10:     2d 15 Jun 02:31
                                                                 BILLQUIST      Johnny Billquist          TT14:   2:03 17 Jun 21:20

FINGER>

Ultra-cool!!

It would appear that there is no carriage return before the line feed.  For the TCP version of finger, you are conforming to the TELNET standard, which wants CR - LF, not simple LF.  As I recall, the Tops-20 DECnet finger server would do the same thing as that is what the client does (recall that it is in a fork and has no idea of what it might be talking to)

Actually Tops-20 finger does functions exactly the same whether you are local or network; that is, a line of text is parsed from primary input (.PRIIN) and the resulting output is typed on the terminal or primary output (.PRIOU).  What happens in the network case is that the backing JFN's for .PRIIN and .PRIOU are changed from the controlling terminal (I.E., .CTTRM) to the network JFN with the SPJFN% JSYS.

When running as such in 'server mode', Finger has no idea of what is going on.  It literally can not tell the difference in input source unless it does some terminal specific things, which it largely doesn't do.  This is how the NETSRV daemon implements the Finger TCP service.

Similarly, when finger is run as a client and asks for a network connection, the protocol is deduced by a table lookup and the line it has is simply shoved over the connection.  The only difference is in the syntax for the constructed JFN.  Code exists for TCP and Pup and it's simple enough to put in a DECnet entry.  I might do that to try it out.

Regarding Batch, it would be difficult to imagine a valid use case for IDLE%.  CPU time is probably fine as it takes processor time to consume characters.  That being said, it's possible that you could have a background task that pops every so often to do some minor thing while the main fork could be wedged.  It all seems a little contrived.

I bring it up because the Tops-20 pseudo-terminal implementation is accurate enough so that I can test certain arcane features such as parity with Kermit-20.  When I use Kermit-20 to establish a local connection over a PTY, it works fine, viz:

 User    Personal name       Job Subsys  Idle TTY Console location
SLOGIN   Thomas DeBellis       8 EMACS   1:21  44 iSnack.Laurel: Development, Large
                      -->     10 FINGER        46 iSnack.Laurel: Secondary Testing, Kermit-20
                      -->     12 EXEC      14. 21 Job 10, SLOGIN, FINGER

You can see that I haven't typed anything into job 12 for fourteen minutes since I pushed to an EXEC to run the finger.

This doesn't happen with the Batch controller, so I've wondered what it might be doing that clears idle.

---

On 6/17/24 3:57 PM, Johnny Billquist wrote:

On 2024-06-17 21:37, Thomas DeBellis wrote:

The finger server simply listened on a particularly port and when a connect was accepted, it was handed off to a fork with finger mapped and the primary I/O JFN's were set to the network connection.  I don'tsee that it is on the PANDA distribution, but it's an easy thing to write.

From a DECnet perspective it's definitely easy. Connection estavlished, client sends one line in the same format as the command line, server responds, just like if you'd get a line and process locally.

I would expect that either the TOPS-20 version also does things slightly differently for DECnet than local, or else it's not compatible with the RSX (and I assume VMS) version.

For a local processing, the command line is provided as a part of starting the process, while over DECnet it will need to read a command line from the DECnet connection. But from there on, it's pretty much the same story either way.

As I recall, it doesn't quite work right with a batch job, but since there is nobody there, this doesn't really matter.  Idle time in that case is detected by CPU consumption.

Idle for batch jobs would be weird. As soone as one thing is completed, the next thing should be started. Where would any idle time be? Unless there is something like a sleep at the CLI prompt level.

  Johnny