17 Jun
2024
17 Jun
'24
11:36 p.m.
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