Gentlepeople,
If you use PyDECnet as an area router, please make sure you're running rev 485 or later. There is a bug in older versions that sends incorrect routing messages to out of area neighbors, causing bad routes.
paul
? I'm working on an 11/73 running Mplus? that is tight on disk space,
to the point that DECnet won't fit. I was wondering if RSX TCP/IP (that
consumes less disk space) would work on a Q bus machine without DECnet.
It's documented as possible for Unibus machines - can it work on a QBus
system?
--
Lee K. Gleason N5ZMR
Control-G Consultants
lee.gleason at comcast.net
--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
A group of DEC collectors out here in Silicon Valley have been getting
together for lunch on the second Saturday of the month for about 20 years
now. The event is known as the "DEC Collector's Lunch", aka DCL (yes, isn't
that clever??), and we typically meet at a local restaurant. However with
the recent virus quarantines, lock downs, and restaurant closures, last
month we held a virtual DCL via Zoom video conference. That worked out
pretty well and it has occurred to me that, since we are no longer fettered
by geography, we could invite people from out of town as well. So, HECnet
users please consider yourselves invited.
We'll start at 11AM PDT, which is 6PM UTC, on Saturday May 9th and the
Zoom conference details are included below.
Bob
Join from PC, Mac, Linux, iOS or Android:
<https://cccconfer.zoom.us/j/91954696002?pwd=ZUtuclNwb0tKWGp4dDhPVmM2ZjlCdz0
9>
https://cccconfer.zoom.us/j/91954696002?pwd=ZUtuclNwb0tKWGp4dDhPVmM2ZjlCdz09
Password: 010929
Or iPhone one-tap (US Toll): +16699006833,91954696002# or
+12532158782,91954696002#
Or Telephone:
Dial:
+1 669 900 6833 (US Toll)
+1 253 215 8782 (US Toll)
+1 346 248 7799 (US Toll)
+1 301 715 8592 (US Toll)
+1 312 626 6799 (US Toll)
+1 646 876 9923 (US Toll)
Meeting ID: 919 5469 6002
International numbers available:
<https://cccconfer.zoom.us/u/ab6LvmtLH9>
https://cccconfer.zoom.us/u/ab6LvmtLH9
Or Skype for Business (Lync):
<SIP:91954696002.010929 at lync.zoom.us>
SIP:91954696002.010929 at lync.zoom.us
Does someone have a VMS system on HECnet with a guest login that I can
use? I need to log in and then SET HOST out again.
I'm working on fixing a few bugs in the DECnet/Linux NML and I need to
make a connection to my Linux machine from a node outside my local area for
testing purposes.
Thanks,
Bob
I've made some fixes to the DECnet/Linux NML server to bring it more in
line with other DECnet implementations, and these are enough to make Paul's
HECnet mapper happy with Linux nodes now. The only changes are to the
dnetnml program, and you can download the new sources from
LEGATO::dnetnml.zip.
FWIW, my changes were made starting from Erik Olofsen's dnprogs-2.68 from
http://rullf2.xs4all.nl/decnet/, but since the only thing that's changed is
dnetnml, I don't think it matters much which DECnet/Linux release you are
using.
And fair warning - this will really only work if your DECnet/Linux machine
is an end node. If your DECnet/Linux is a router then it will undoubtedly
return some wrong answers (and you will also mostly likely have bigger
problems than NML to worry about!).
Thanks, Paul, for answering my questions and explaining stuff to me.
Bob
The Cisco DECnet router implementation does not speak "decnet management" as
we all knew. The way we are using them the tunnel end-points are on the Internet.
Most of the information "missing" is actually available through the SNMP MIB,
so if we could agree on a common read-only community and publish the IP addresses
of those routers it would be possible to complete Paul's map..
Attached info.
-P
I got a request from someone. Not anyone I know, and since I don't
normally have any VMS systems up and running, I can't really help.
I'm sending it on here in case anyone feel generous in helping the guy
out...
Johnny
-------- Forwarded Message --------
Subject: Request for access to a VMS system
Date: Tue, 5 May 2020 16:49:12 -0700
From: Steven Schoch <schoch6 at gmail.com>
To: Johnny Billquist <bqt at update.uu.se>
Hello Johnny,
I got your name from Eric Fair when I asked about a VMS system on a group.
I long time ago I wrote a module (for an X Windows terminal) that would
use a chat script to login to VMS using telnet. I haven't had access to
a VMS systems for years, but a user of my script wanted to use it, and
said it wouldn't work.
So I'd like to troubleshoot it, but I don't have access to a VMS system.
Would you be willing to give me temporary access, just long enough to
test my login script?
Thanks in advance.
--
Steve
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
From: R. Voorhorst [mailto:R.Voorhorst at swabhawat.com]
Sent: Tuesday, 05 May, 2020 12:04
To: 'owner-hecnet at Update.UU.SE' <owner-hecnet at Update.UU.SE>
Subject: RE: [HECnet] More NRT --> VMS and others
Hi Thomas,
I use NRT frequently on the older systems as CTERM does not work well with
them; often bursty IO.
On VAX/VMS, NRT usually works well, at least as host and cooperates well
with Tops10/Tops20 Panda.
Also on Rsx11M and Rsts 10.1.
Sethost on Tops20 Panda to VMS however does not:
sethost
Escape character(^Y):
Host name: swbv89
? Communication with VMS not supported by SETHOST
Even on OpenVms alpha 8.3 it works to vax, however with connection to
tops10/20, the process crashes with an exception.
Maybe it could be repaired on Alpha, but I doubt sufficient sources are
around.
You can test initial connect on Swbv55 on hecnet when it is up, as it is a
VAX VMS 7.3 hecnet area router, though you cannot login on it (yet?).
Best regards,
R.V.
From: owner-hecnet at Update.UU.SE <mailto:owner-hecnet at Update.UU.SE>
[mailto:owner-hecnet at Update.UU.SE] On Behalf Of Thomas DeBellis
Sent: Tuesday, 05 May, 2020 07:14
To: hecnet at Update.UU.SE <mailto:hecnet at Update.UU.SE>
Subject: [HECnet] More NRT
What's fun about the Tops-20 NRT client (SETHOST) is that it doesn't do much
aside from parsing for an escape character and node name. It builds a
connection string and checks to make sure the remote system is either a 10
or a 20. Then it twiddles a few things on the terminal (a few more if
you're running my changes to handle page mode). Finally, and this is the
cool part, it issues an MTOPR% to directly connect the local user's terminal
to the open DECnet connection (port 23).
Thereafter, the client does nothing until the interrupt character is typed
or the connection is broken. So response can be pretty snappy because you
are never running in user space; no context switching. The CTERM client on
the other hand is reading and writing data and otherwise handling the
specifics of the protocol in user space. So, more overhead and more context
switching.
As an experiment, I removed the checks for Tops-10 and Tops-20 and tried
connecting to a few hosts on HECnet.
* Tops-20; TOMMYT and TWENEX worked (of course)
* Tops-10; VENTI worked
* RSX-11+; MIM accepted the connection and broke it as soon as I
started typing.
* VMS; LEGATO accepted the connection and broke it as soon as I
started typing.
* RSTS; TRON accepted the connection and then did nothing. It never
broke the connection, but never displayed any banner or anything else. It
appeared hung.
So it would appear that NRT servers only exist on the 36 bit line. Perhaps
it's possible to configure the service for other platforms?
The first few RSTS systems I tried didn't appear to be online; MEZZO, PLUTO,
RSTSE and BITXOT. The few Windows systems I checked didn't appear to be
online, either; WXP, MISSY, KIBBEH and WATAN. I'm not sure if that means
they refused the connection attempt outright.
