As we are preparing our relocation to Oregon, I have shut down my home network almost completely taking down all my HECNET nodes.
I expect them to be back online in May or June
Mike
Some time ago in 2024, while I was writing the Tops-20 Finger Server,
Johnny and I collaborated on a finger specification for Finger over
DECnet. By 'collaborate', I mean I tried putting something together and
Johnny pointed out the mistakes and things iterated from there. It is
hopefully better than an RFC.
The major difference from the Internet specification is that the
protocol more closely aligns with a record orientated paradigm which is
more appropriate for DECnet applications. It can be told to do
otherwise and stream large buffers, but the default is for the
application to limit messages to line at time of no more than about 100
characters. I don't remember if I ever publicly announced availability,
but it can be found on VENTI2::DECNET-FINGER-SPECIFICATION.TXT for
anonymous NFT.
The Tops-20 Finger server itself was effectively complete enough last
year that I felt it appropriate to write a setup guide. It can be read
as a companion piece to the DECnet specification for more background
information on how to implement the protocol.
Further, and perhaps of more interest, it shows how to set up a network
service on Tops-20 without Operator capability, which makes the server
safer to run. Think of not using Administrator (on Windows), root (on
Ultrix), or SYS:, JACCT or [1,2] (on Tops-10) if you know what those
are. I don't know what the equivalent is on other DEC operating
systems. It can also be found on VENTI2::FNGSRV-SETUP.TXT.TXT for
anonymous NFT.
If there are other DECnet finger clients on HECnet than Johnny's or
mine, I would be delighted to hear about it. It's pretty trivial; you
open a connection to a remote host on object 117 (decimal) and send
either a carriage return, a line feed (which gets you the default full
system listing) or a user name followed by one of those two characters.Â
You then read responses and print them until the connection closes.Â
That's it. That's all.
Maybe a one or two line Python program? I could probably still do a
trivial BLISS Common client, but I don't recall having learned the
DECnet API for VMS. At Marlboro, the little Bliss work that I did was
for Tops-20 and Tops-10 and didn't do DECnet. Supposedly, it would have
been easy enough to run on VMS, but I never had the opportunity.
The only DECnet finger servers that are in full time production that I
am aware of are running on MIM:: and VENTI2::. TOMMYT:: runs it on an
experimental basis, but requires a monitor upgrade and reconfiguration
to do a full installation in order to go into production. I'll do that
later this year, I hope.
Version 5.3(297)-5 incorporates additional features, enhancements and
fixes since the minor release of 5.3(277)-5 in 30-Aug-2024. These are as
listed below and can be identified in the source code with the edit
number as the prefix of a comment.
As a courtesy, it is being made available early to users of the HECnet
community prior to the tarball being posted on the Internet. It may be
anonymously NFT'ed from VENTI2::TOMMYT:<OINKY.K20MIT> and related
subdirectories.
The changes are briefly summarized below and are further described in
TOMMYT:<OINKY.K20MIT.DOCUMENTATION>KERMIT-20_V5_3_297-5-ANNOUNCEMENT.TXT.
Rich text is also available in .PDF and Microsoft .DOCX format.
Please email me any issues with FAL transfers off list and I will
investigate.
------------------------------------------------------------------------
[278] Modify DEFINE/SAVE to allow another terminal we've assigned
[279] If doing parity, show count of parity errors in STATUS if non-zero
[280] Catch an edge case of a missed parity substitution for a single
character
[281] When logging, do not issue an error message if not local
[282] Fix no blips when logging packets on a local terminal
[283] Specifically identify and log a time out packet, if logging
[284] PUSH [/CONTINUE /RECREATE /RESET (/KILL)]
[285] Rework capabilities when PUSH'ing
[286] Rework POP logic to handle the arcane case of being detached
[287] /NO-MACROS switch to SHOW (ALL) command
[288] Replace an unrolled LSH/IDPB loop with MOVSLJ.
[289] Fix fast multi-generation delete for server
[290] Move some more constants into CONST .PSECT
[291] Properly handle 30 bit one word global pointer in string error
processing
[292] Fix fast multi-generational delete for all wildcards
[293] Fix reporting for no Control-C capability
[294] Do an SFPTR% on every PMAP% in mapi:.
[295] Manage debugging of 36 bit transfers a little better
[296] Fix directory header which I subtly broke with [193]
[297] If no ^C, mention it on SHOW LINE
Kermit-20-Testing-Battery-5.3(297)-5 Updates
On 11/27/2025 3:45 AM, Terri Kennedy wrote:
> Â Dave says this is the first time he has been in the same
> room as a working 780. Yay! And a big shout out to all of
> the volunteers who have been working to get this system run-
> ning, with work starting all the way back in 2018!
>
Yay Dave! I have had the pleasure of knowing 3 different VAX-11/780 systems. The first was the one we got at Rose-Hulman over the summer of 1980 to supplement our PDP-11/70 and 11/45. I believe the 11/45 might have been traded in as part of the VAX purchase. Things are hazy. The other two were in 1983 when I went to work at DePauw University in Greencastle, IN, just up I-70 from Terre Haute and Rose. There were one each for the academic and administrative sides of the school. I was hired on the administrative side as one of the programmers to convert their BASIC PLUS 2 applications on their PDP-11/70 to VAX BASIC on the VAX-11.
--
John H. Reinhardt
I am pleased to announce that we at LSSM have just gotten our
VAX-11/780 up and running!
Now we have to clean up the debugging and repair mess, clean up the
cabling, arrange for a permanent system disk, etc, then we will declare
it an "operational exhibit". Once that's done, it will be on HECnet
whenever it's up and running.
Of course all are welcome to come to LSSM in person and run the
machine. (feel the rumble in the floor, etc)
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
A few additions. Owen and I were working on it most recently; Matt
and Richard are not in town now. But both have put effort into it. A
lot of us have; this poor machine took a lot of work to get going.
You missed its initial troubles just before your first visit. We
picked up the machine that summer of 2017 and it was a MESS. From
memory, I hope I don't miss anything, here are the things we worked on
initially:
It had an FP785 installed; we removed it and installed baffles. (will
an FP785 even work in an 11/780??) We left the first power supply in
place in case we find an FP780 board set.
Three of its four power supplies needed bench work. The fourth was
fine. (We don't know the status of the FP780 power supply yet; we'll
look into that if we ever find an FP780.)
The console PDP-11/03 was missing, I built one from parts.
The backplane covers were missing and there were a few groups of
mashed pins. We straightened those, and found and installed the covers.
There was a UBA, but no Unibus chassis. We put together a BA11-K for
that. (We later found its original Unibus chassis.)
Later after Terri spent DAYS tediously combing out the huge mess of
board revisions (the previous owner kept swapping things around trying
to get it running) she got all that straightened out and then figured
out what WCS version we needed. Mike up at RICM was able to supply a
copy, but their disk imaging system was down so he just sent us the
whole box of disks. We imaged them and sent them back, and I pieced
together what should look like an original distribution 11/780 console disk.
This was a big thing for me personally too. All my life I've been a
"DEC guy"; I've had VAXen at home since I was 20 years old, which was 36
years ago, almost as long as I've had PDP-8s and PDP-11s. My first
"real" industry job was as an admin on a set of VAXen, one of which was
an 11/750. But until last night, I had never been in the same room as a
running 11/780. It hit me deeply and felt really, really good.
And it was fitting for Owen; he was at the console during the first
complete boot, and yesterday was his 65th birthday. A few of us took
him out for tasty Indian food right after that boot.
-Dave
On 11/27/25 04:45, Terri Kennedy wrote:
> On 2025-11-27 02:56, Keith Halewood wrote:
>> Great news. I hope you'll be publishing some pictures (perhaps before,
>> during after) of the restoration on the website?
>
> Â There aren't a lot of pictures (at least I didn't take many).
>
> Â A lot of it was just basic mechanical stuff - fixing a seized
> spindle and decayed drive belt on the floppy drive and then im-
> aging a number of floppies with the console software and a bunch
> of diagnostic discs. Dave did all of that.
>
> Â Then there was an interesting project to come up with outlet
> strips to plug all of the individual component AC power cords
> into, since there wasn't an L21-30R receptacle there at the time
> to plug the single "official" power cord into. This will be ad-
> dressed now that it is a functional exhibit.
>
> Â After reseating some cards, Dave and I were able to use a
> cheat I knew of to get past the console complaints about mis-
> matched hardware and we got the first ">>>" prompt in over a
> decade. At that point, "BOOT DU0" would actually go initialize
> the disk controller and turn on the port select on the drive,
> but not go past that point. At that point, we knew we at least
> had a VAX, although a very sick one.
>
> Â At that point, Dave imaged some other console discs and I
> then edited the contents using RT-11 on another system (the
> LSI-11/03 that controls the VAX runs a very modified version
> of RT-11).
>
> Â Next, there was an assortment of boards which were neither
> compatible with each other, nor with the console microcode.
> I discovered the Museum had nearly a complete 780 board set as
> well as some 785 boards, and spent several days with all of
> the boards and DEC's official "VAX-11/780 & VAX-11/782 Revis-
> ion Control" document to bring the system up to revision 8.B
> which is the newest 780 revision. I then spent a few more
> days weeding out bad boards.
>
> Â At that point, the system went from saying "Help me!" (see
> the first photo) to actually booting to the VMS version banner
> for the first time in many, many years (second photo) but then
> hanging.
>
> Â Dave, Owen, Richard and Matt P (apologies if I missed any-
> one, I'm doing this from memory) then discovered that I'd
> missed a bad board, which caused "console transit done" in-
> terrupts to not be seen by the VAX. This past evening, they
> got the 780 to boot, first NetBSD and then VMS. It is also
> now passing diagnostics.
>
> Â Now the work begins to neaten things up, get it the power
> cabling it wants, and configure the console floppy so that
> it can boot VMS, Ultrix-32 or NetBSD, depending on what sort
> of demo will be given.
>
> Â Dave says this is the first time he has been in the same
> room as a working 780. Yay! And a big shout out to all of
> the volunteers who have been working to get this system run-
> ning, with work starting all the way back in 2018!
>
> Â Th last picture is the inside of the 780 in all of its
> glory. It isn't on in this picture because the air baffles
> need to be in place in front of the cards to keep the CPU
> from overheating and going into thermal shutdown. So this
> picture was "posed" to show the board set, before putting
> all of the air baffles back in place.
>
> _______________________________________________
> HECnet mailing list -- hecnet(a)lists.dfupdate.se
> To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
--
Dave McGuire, AK4HZ
New Kensington, PA
Hi folks, has anyone here used a Lantronix ETS-series or similar
terminal server for LAT connections to RSX? We're having a strange
problem at LSSM and could use some info.
Thanks,
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
Time for a new release announcement of TCP/IP for RSX-11M-PLUS.
This is version 2.18 of BQTCP/IP.
It's been a while since the last release, and quite some improvements
have been done in several subsystems. Some of them are rather
significant, and a recommendation to update to this new version soon is
recommended.
Highlights:
. IP logging facility have been added, logging various bad packets.
. Improved IP multicast handling.
. Added functionality to have system not respond to Multicast packets
that could potentially be abused for DDoS attacks.
Detailed information on things that have been done since the last release:
Ethernet:
. Bugfix. The initial multicast list enabled on ethernet was wrong at
the MAC level.
. Bugfix. Network directed broadcasts did not get correct dst MAC.
. Various optimizations and improvements handling broadcasts, multicasts
and route lookup processing.
. Bugfix. ETHACP didn't properly pick up ethernet multicast indication.
IP:
. Improved statistics around IP fragmentation.
. Added IP transmit broadcast statistic
ICMP:
. Bugfix. ECMP ECHO requests to broadcast was responded with a MAC
broadcast, even though we had an IP address it should go to.
. Improved ICMP histogram statistics handling.
IGMP:
. Bugfix in IGMP. Timer processing for IGMP reports didn't work properly.
UDP:
. Added information about broadcast and multicast response block to UDP
receive IOSB.
TCP:
. Changed TCP to still deliver received data if remote does an RST after.
. Clean up TCP reset handling.
. Cleaned up TCP counters.
. Improved TCP QIO write operations to include CR+LF if VFC says so for
any mode.
. Changed conditions for TCP keepalive vs. window probe.
DHCP:
. Improved DHCP client to do broadcasts that are not looped back.
. Improved handling of address changes in DHCP and router table.
. Changed resolver to not use DHCP provided resolvers, if a more
specific resolver have been requested by logical name.
DNS:
. Added more logging about tracking bad server in DNS.
. Bugfix in DNS. Under some circumstances, the parsing could reject
correct packets.
. Changed DNS to better handle CNAMEs.
. Improved handling of non-responding DNS servers in resolver.
. Bugfix. RESACP didn't properly detect truncated responses.
. Bugfix. RESACP failed to properly handle F11 hostnames.
IFCONFIG:
. Added HELP command to IFCONFIG.
. Added IFC SET IP MULTICAST RESPONSE ENABLE/DISABLE and IFC SHOW IP
MULTICAST.
. Bugfix in IFCONFIG with SHOW LOG failing.
. Changed IFCONFIG to always show interface network mask numeric.
FTP/FTPD:
. Bugfix. FTPD got into a bad state if a directory listing was requested
with an illegal file name, or other error.
. FTP improved error handling in communication.
. Bugfix. FTP/FTPD could get the wrong file if a directory operation was
done before reading a file.
Multinet:
. Added handling of transmit errors in Multinet.
. Added calling SPOOF from Multinet when there seems to be bad behavior
from a remote host.
RWHOD:
. Improved rwhod error reporting.
SMTP:
. Improved SMTP send hostname processing.
. Improved SMTP mail sending.
LOGGER:
. Added IP LOGGING task and functionality.
TELNETD:
. Bugfix in TELNETD. Under some circumstances, TELNETD could crash the
system.
LPT/LPQ:
. Improved LPT and LPQ printer logical name processing.
RMD:
. Changed RMD task header page to show more information on TC:
Some additional notes:
As usual, I would recommend people to update as soon as possible.
The changes are somewhat critical, but will also lead to a much better
experience.
The patches to the TT: driver cannot be applied automatically, but
requires users to apply the patches themselves, and then run SYSGEN to
generate a new system.
Once added, the TNC2 task can be run at login, and will define logical
names for the user telling where he is connected from, if using telnet,
DECnet or LAT.
TNC2 can get information about remote connections over DECnet as well,
but this requires updates to DECnet. Such patches are not available
separately at this time, but are included in the RSX image provided from
Johnny Billquist.
The TT: driver patches also allows the updated MCR to give more
information with the DEV command (SHOW TERMINAL in DCL).
The patched TT: driver also makes is possible to get telnetd fully
vectorized, as this version provides two more addresses that are
required by telnetd to access information in the kernel.
The other patches to RSX can be applied automatically by IPGEN, either
if used interactively when answering YES to the question about applying
RSX patches, or by running IPGEN explicitly to do the patches, with the
command:
@IPGEN PATCH
Specific information about the patches:
LAT: Fixes a memory leak, and adds the ability to read where a terminal
connection comes from when using LAT, using SF.GMC.
RMSDAP: Fixes a bug in getting the file protection, so the XAB gets
filled in correctly for remote files.
RMSDSP: Fixes that some numbers were displayed in signed octal, which
should have been displayed in decimal or unsigned octal, depending on
number.
DCL: Added terminal attributes for COLOR.
MCR: Too many fixes to be listed here...
INS: Fixes that users cannot circumvent protection on common regions.
HEL: Fix that users can login with session ID, or with directory, in
addition to name and UIC.
ACNT: Add no password change attribute to accounts.
PSW: Add no password change handling.
SYL (SYSLOG): Add terminal idle tracking on accounts without idle logout.
ECL: If the receiving machine is very slow, and the sending machine is
very fast, and the receiver announce several large buffers available,
ECL cannot keep up, and drops packets. This is a problem with the DECnet
flow control, as it is used in RSX. The simple solution is to allow more
outstanding buffers when receiving. A more complex solution would be to
change how RSX DECnet do flow control, but that would require rewriting
a fair chunk of the ECL module.
NMVACP: Fix handling of "show known nodes" command, which could skip
some nodes.
NVP: Add ability to use session ID or directory name for user identity
in DECnet nodename specifications.
EPM: Fix handling of ethernet multicast.
NTDEMO: Fix that hosts without names should display DECnet address.
NCP: Parse of additional information types in NICE messages.
*** NOTE ***
MIM have moved to a new address, and a new name. The correct name is now
Mim.SoftJAR.SE. I hope that this will now not need to change again.
*** NOTE ***
As usual, the distribution is available from:
ftp://mim.softjar.se/bqtcp.dsk
ftp://mim.softjar.se/bqtcp.tap
!!! BQTCP is also available through RPM !!!
(As an additional note, if there are any problems communicating with Mim
using port 21, the ftp service is also available at port 10021)
The documentation is also available through ftp on Mim, or also at
http://mim.softjar.se/tcpipdoc
I hope people find this update useful.
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
Hey, fellow DECheads! I'm proud to announce that the Large Scale
Systems Museum is approaching the 10th anniversary of its first public
opening. We are doing a fundraiser event on October 17th and 18th, and
we have a few slots left. If you can't make it in person but still want
to contribute, there's a way to purchase a "non-attendance" ticket.
LSSM is a 100% donor-funded 501(c)(3) nonprofit public museum based
in Pittsburgh, PA, USA. All fundraiser proceeds to directly to funding
museum operations.
Sign up here: http://www.lssmuseum.org/10
Thanks,
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
MIM needs to be taken down for about 1 hour on Fre Sep 12, at 9PM UTC.
Just a heads up for all people, so they know it's happening.
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