17 Jun
2024
17 Jun
'24
9:57 p.m.
On 2024-06-17 21:37, Thomas DeBellis wrote:
Columbia did an DECnet finger server for Tops-20. As
I recall, wefirst
used the same numeric object type as TCP (I.E., 79), although 117 does
not sound unfamiliar for some strange reason... We certainly could have
changed it, but I don't remember why. Is something else on 79?
Not anything I know, but I've never seen an exhaustive list of objects
defined for DECnet either. Heck, the RSX DECnet manuals don't even go as
far as tell that Datatrieve is object 63, instead claiming that objet 63
is "RSX DECnet test tool", whatever that might be.
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.
PANDA Tops-20 handles terminal idle time in a somewhat
obvious way: the
system uptime (in milliseconds) is stored in the terminal block whenever
input is detected. Idle time is computed by subtracting that uptime
from the current uptime. This gives you a nice exact number.
With RSX, there is a daemon that is responsible for logging users out
which have been idle long enoguh, so it scans every minute if something
was done on the terminal. If not, the idle time is incremented. So it's
accurate, but the resolution is in minutes.
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
--
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