18 Jun
2024
18 Jun
'24
3:41 a.m.
Hmm. To maybe clarify myself a bit.
In RSX, the FINGER program is the same binary for both the client and
server side. If that is not the case under TOPS-20, then I get it.
In RSX, if you just run finger, it will get the command line, and then
pull the information from the local system based on that, and print
things out. If it detects that it was started because of an incoming IP
or DECnet connection, it will instead read a line from the network,
which will then be processed the same as a command line, if it had been
invoked locally, and then print all the results out on that network link.
And finally, if invoked by a user on a terminal, and it detects that the
command line contained an argument which included "@" it would go on and
just connect via IP to the host, send the command line, and then just
read from the network and print on the terminal until EOF, and equally
if the command line contained "::" it opens a DECnet connection, sends
the command line, and then just loops reading from DECnet and printing
on the terminal until EOF.
Johnny
On 2024-06-18 03:29, Johnny Billquist wrote:
On 2024-06-17 23:36, Thomas DeBellis wrote:
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
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.
Hmm? How does command line processing work under TOPS-20?
If you type:
@ FINGER MIM::
would the finger program be started, and it would do a read from the
terminal to read a line, and it would actually get the command line
"FINGER MIM::", or actually, would it get "MIM::" in that case?
Because
that is how it would need to be in order to work the same if it came via
DECnet.
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.
Well, my questions are specifically about how it get some command line
stuff here. For the rest, for sure I can see that it wouldn't be aware,
or have any need to.
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 isin
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
itout.
The "line it has" it what my question is about. If you run locally, I
wouldn't expect it to talk to anything, but simply pull out the
information from the local system itself. Are you saying that the client
always calls a separate backend under TOPS-20?
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.
Yeah. I would generally not consider batch jobs to make sense to talk
about in the context of idle processes.
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.
Obviously I have no idea. :-)
Johnny
------------------------------------------------------------------------
On 6/17/24 3:57 PM, Johnny Billquist wrote:
On 2024-06-17 21:37, Thomas DeBellis wrote:
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se 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 inthat
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