24 Jul
2024
24 Jul
'24
12:44 a.m.
Personally, I've never particularly liked the .#transport suffix stuff.
Actually, I thought it was kind of ... yech ...
After all, there was more than one DECnet at the time, so you could have
one Internet host on one DECnet with another Internet host on a
different DECnetg. This was the case with DEC-MARLBORO, 2102 and CU20B
which had different DECnets. One assumes that there could have been
more than one Chaos and Pup transport, too. I forget how we did bitnet,
but we handled that, as well. And then there was that AT&T "!" stuff...
On the other hand, I was never sufficiently clever enough to think up an
alternative that was general enough and more straightforward then this
suffix scheme. There were also some pretty titanic personalities
involved, too, so I didn't want to get near any of that either, as I was
getting paid to do other things.
Now that I'm thinking about it, the system manager for CU's Chemistry
VAX-11/780 did suggest the DECnet node form for finger, as in @finger
cuchem::slogin. This seemed reasonable to me, but it got voted down as
it wouldn't work for Internet hosts that were longer than six characters
and I forget why else. I had thought it would be very friendly to try
to accommodate this, but I wasn't assigned to the EXEC. And those pesky
titanic personalities waging their flame wars...
Since the transport preference has been ordered to try DECnet first, I
think the following would be easy enough to do, assuming a stripped down
BNF:
@finger [username[(a)host.[#transport]]] | [node::[username]]
Examples:
1. @finger would give everybody on the local machine
2. @finger username would give username on local machine.
3. @finger username@host would pick DECnet first, then try Internet and
so on
4. @finger username(a)host.#transport would force a particular protocol
5. @finger node:: would give all users on a particular DECnet host
6. @finger node::username would give a particular user on a particular
DECnet host.
I think that might be doable in the EXEC with the right break masks and
function types (I.E., .CMUSR, .CMNOD, and .CMFLD). It would probably
need some tweaking.
I'll put this on the (very long) To Do: list.
------------------------------------------------------------------------
On 7/23/24 5:35 PM, Johnny Billquist wrote:
On 2024-07-23 22:11, Thomas DeBellis wrote:
Probably I am now the worst person in the world
to ask as to what is
intuitive on Tops-20, what with being saturated with it and all.
Are you referring to the programming part or the user part?
I am referring to the convoluted notation to tell which protocol to use.
debellis(a)mim.#decnet
vs.
debellis(a)mim.#internet
If the latter, then what is so bad about _@finger
debellis@mim_?
It's the same thing you'd use for email... I don't recall that our
users complained about finger. They did, however, find plenty of
other things to point out.
That's the thing. Using that notation also for mail? Ugh! There was a
convention used everywhere else, which is basically:
debellis(a)mim.stupi.net (or shorter, if domain match, or if you have a
hosts file, or whatever)
vs.
mim::debellis
This is what everything else have been using all this time, and it
makes it much easier, unambiguous, and I would say very clear. It also
carries over to protocols like DAP, where instead of usernames you
have filename paths, which can include a host, and is then separated
by the double colon. I would assume TOPS-20 do understand that
notation for files at least?
If you want complicated, unintuitive and bad to
use, may I suggest
trying to create a directory on ITS or deleting a file on MVS with JCL?
Oh, I'm sure if you want to, there are any number of examples of
horrible and unintuitive examples all over. It's just not something I
thought TOPS-20 would get to. Generally, I have always considered
TOPS-20 to be rather the opposite. So this is a bit of a surprise (to
me).
Johnny
------------------------------------------------------------------------
On 7/21/24 6:42 AM, Johnny Billquist wrote:
I must say - in this case TOPS-20 seems rather
complicated,
unintuitive and bad to use.
The user and hostname fields... Hmm. I'll clean that up on the RSX
side. :-)
Johnny
On 2024-07-21 04:02, Thomas DeBellis wrote:
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se I finally remembered the syntax to force
transport. After you
aredone with whatever the host name is, you append a ".#" suffix
followed by the name of the transport protocol. Let's suppose
there is a nickname defined in the SYSTEM:HOSTS.TXT file for MIM::
as follows:
HOST : 192.108.202.74 : MIM : PDP11 : RSX :
TCP/TELNET,TCP/FTP,TCP/SMTP,TCP/FINGER :
So we can force a finger of user DEBELLIS to use a particular
transport, as below. In the output, the DCN: device is the DECnet
active component (or client) and the TCP: device is for IP, where
client or service are specified in the GTJFN% string.
*DECNET*
FINGER>debellis(a)mim.#decnet
[Fork FINGER opening DCN:MIM-117 for reading, writing]
DEBELLIS
Default directory: US00:[DEBELLIS] CLI: DCL SID: TDB
Last seen May 21 2024 23:56:54 on RT0: from VENTI2::
Logged on 8 times.
No plan.
*INTERNET*
FINGER>debellis(a)mim.#internet
[Fork FINGER opening
TCP:.30033145112-79;PERSIST:30;CONNECTION:ACTIVE for reading, writing]
DEBELLIS
Default directory: US00:[DEBELLIS] CLI: DCL SID: TDB
Last seen May 21 2024 23:56:54 on RT0: from VENTI2::
Logged on 8 times.
No plan.
I did notice that the user and host name data appear to be written
in fixed length fields, resulting in trailing spaces that were not
trimmed. This is unlike the other lines in the output. Not thatit
really matters; who is running 300 baud these days except for museums?
> ------------------------------------------------------------------------
>
>
> On 7/20/24 7:27 PM, Thomas DeBellis wrote:
>
> All too true, except that it isn't stupid, at least not in that
> particular regard.
>
> As per my previous email, Finger uses HSTNAM to determine network
> transport, which has a default order, on my systems picking DECnet
> first. I'm pretty sure there was a way to force the transport
> protocol, I just don't remember what the magic syntax is.
>
> A number of system programs use HSTNAM to implement their
> protocols over multiple transports. These include the mail
> system, the FTP client, finger and something else (I think).
>
>> ------------------------------------------------------------------------
>>
>>
>> On 6/17/24 9:22 PM, Johnny Billquist wrote:
>>
>> Ugh. That notions seems risky... How do you know you should be
>> using DECnet and not IP if you say @mim?
>>
>> After all, @mim is a perfectly valid IP address as well.
>>
>>> ------------------------------------------------------------------------
>>>
>>>
>>> On 2024-06-18 00:47, Thomas DeBellis wrote:
>>>
>>> Updating the Tops-20 Finger client was simple enough, a table
>>> entry for DECnet and a small routine to build the JFN string, viz:
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se