Thomas - checked a little on the RSX side.
I'm getting a data overrun error when receiving from VENTI2::
How much data are you sending in a single buffer???
Johnny
On 2024-09-17 21:48, Thomas DeBellis wrote:
Thanks, Terri, that is very kind of you to offer
this.
What a finger client will accept and produce has always been highly
installation dependent, the only consistency between all of them
being that the local folks thought theirs was the best, the highest
complement being when one finger adopted another finger's feature.
Tops-20 Finger will accept the following:
/CPU-IDLE /DETACHED /DIAL-IN /ETHERNET
/FULL-USER-NAME /HELP /INTERNET
/JOBNAME: /LOCAL /LOGIN /NETWORK
/NO-DETACHED /NO-OPERATOR /NO-PLAN
/OPERATOR /PTY /REAL-LOCATIONS /TERSE
/TTY-IDLE /TTY: /TYPE:
/VERBOSE /WHOIS
As can be seen, it is almost, but not quite entirely DECnet innocent,
which is not surprising as this is Standford's finger. It's an
accumulation of many years of separate authors and separate styles
and hacks that is kind of crying out for a substantial if not
complete rewrite. I don't believe I will have time for that for
another two years. For now, I'm just trying to get it to work on
DECnet without too many sparks flying out.
Columbia's finger did do a better job, but the underlying
implementation was another can of worms. Besides, those sourcesare
lost.
/COMMENT sounds interesting, but as I said, I'm still draining the
swamp, as it were and have not gotten past the alligators.
------------------------------------------------------------------------
On 9/16/24 10:29 PM, Terri Kennedy wrote:
> ------------------------------------------------------------------------
>
> On 2024-09-16 22:05, Thomas DeBellis wrote:
>
> As can be seen, the Tops-20 finger client has been modified to send
> the name of the local user and optional data identifying the finger
> client. Probably I'll change that to the finger version. The RFC
> for TCP/IP finger is (naturally) silent on what you can send over
> DECnet, so this doesn't break anything. So, I can finger myself on
> MIM:: just fine, viz:
DECnet uses the same sorts of qualifiers as the TCP/IP version.
I had added a "/IAM=" qualifier to both VMS and RSTS/E Finger,
but it is too easily abused in the modern age, particularly where
not all nodes are under common management. The original intent was
to have the server display "The user has the following unread mail
messages from you" with a number, date/time, and subject.
I will be removing it from both VMS and RSTS/E Finger (it will no
longer send /IAM and will silently ignore any incoming /IAM).
> If you have a finger client that can do DECnet connections on
> another platform (I'm thinking VMS or maybe RSTS) and can try it,
> let me know how you make out. Be aware that I did just hack this
> together in two and a half days, so I make no claims to any sort of
> stability. I'm just trying to trouble shoot at this point.
As soon as I get on HECnet, I'll be glad to do any
interoperability testing you want (and both the VAX and RSTS/E
systems will have guest accounts, so you'll be able to log in and
test for yourself).
The currently implemented qualifiers in VMS Finger are:
/ALL /BATCH /BYPASS /CPUTIME /FULL /HELP
/IDLETIME /IMAGENAME /INTERACTIVE /LOCATION /LOGINTIME
/MESSAGE /NETWORK /PERSONALNAME /PID /PROCESSNAME /SIZE
/SORT /STATE /SUBPROCESS /SWAPPED /SYSTEM /TERMINAL
/TTTYPE /USERNAME
RSTS/E Finger ignores the ones that aren't relevant to that
platform (or aren't implemented).
I propose we add a "/COMMENT=quoted-string" qualifier.
Implementations that don't support it will either complain or
silently ignore it. Implementations that support it may choose to
log that info (and anything else they care to) in an
implementation-specific manner. I further suggest that the comment
have a formal (if undocumented 8-) syntax, for example:
/COMMENT="NODE:nodename,USER:username,VERS:finger-version"
This will let humans (and possibly programs) parse that info with
relative ease.
What do people think about that?
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se