Hi, all.
If you are running an RSX system on HECnet, and you'd like a simple
command line tool to check some information about other nodes, as it is
registered in the Datatrieve database I keep on MIM, I've written one now.
It does require that you have the PDP-11 C runtime libraries installed
(they are installed as a part of BQTCP, and also exists as a component
in RPM).
Just grab MIM::HECNET:DDB.TSK, install it, and off you go.
If you want the sources (it's really simple) they can be found at
MIM::HECNET:DDB.C and you also have a Makefile there that compiles it
for you, in case you want to experiment some.
Example run:
.ddb mim
Node: MIM
Address: 1.13
Owner: Johnny Billquist
OS: RSX-11M-PLUS V4.6
CPU: PDP-11/74 (e11)
Created: 12 Nov 2011 12:00:00
Modified: 02 May 2020 19:45:49
Loc: Uppsala, Sweden
Coord: 59.858612,17.638744
.
I just thought it could be useful to have sometimes, and it's also a
good exercise in interfacing between Datatrieve and PDP-11 C.
Johnny
--
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
Has anybody ever seen SETNOD fail to insert the entire node list?? I
just did.
Shortly after I put my 20's up on HECnet, I wrote a reoccurring batch
job that fires once a week on Sundays to pull the latest node list
(T20.FIX) from MIM::.? I use the highly venerable FILCOM program to do a
difference of it with the previous week's list.? I don't do anything in
particular with the output except save it in case I feel like looking at
it for some reason.
The batch job always inserts the entire list, rewriting whatever might
be in the monitor's data base.? I have always been unsatisfied with
doing things that way because it seemed to me to be inefficient as the
node list grew.?? The HECnet node list count was 716 on 9-Jun-19 and
it's now up to 884 as of the latest version that I've pulled,
30-Apr-21.? The other problem is the microscopic possibility that a node
is in Tops-20's monitor database (a hash table) that isn't in the HECnet
node list.
Nodes can get removed, although I think that infrequent.? Nodes could
get inserted outside of the batch job, but I think that most unlikely in
my situation.? Nodes can get renamed, as evidenced by 2.299 below, which
went from THEPIT to THEARK.? None of this should or has broken anything.
However, it's been in the back of my mind to do two enhancements, one to
Tops-20 and one to SETNOD. The NODE% JSYS should have an additional
feature to return the current monitor data base.? The SETNOD program
should be enhanced to take that to compute the set difference with the
new list.? This would show additions, renames and deletions. That would
bring the update operation down from some hundred items to less than
ten, on average.? This would obviously make more of a difference on huge
DECnet's in the tens of thousands of nodes. Another NODE% feature should
probably be to whack the entire monitor database except for the local
node, which would be useful for trouble shooting.
Last Sunday, the batch job failed with the following error:
18:33:40 USER?? SETNOD>*TAKE SYSTEM:NODE-DATA.TXT.0
18:33:40 USER
18:33:40 USER?? [Fork SETNOD opening <SYSTEM>NODE-DATA.TXT.1 for reading]
18:33:41 USER?? SETNOD>*SAVE
18:33:41 USER
18:33:41 USER?? [Fork SETNOD opening <SYSTEM>NODE-DATA.BIN.74 for
reading, writing]
18:33:41 USER?? SETNOD>*INSERT
18:33:41 USER
18:33:41 USER *?SETNOD: Failed at node REACH*
18:33:41 USER?? SETNOD>
I had a look at the SETNOD source and the HECnet node list and have
discovered and concluded a few things.? First, there doesn't seem to be
anything syntactically wrong with REACH::'s definition: "set nod 2.298
name REACH". Second, there don't appear to be any semantic issues.?
2.298 wasn't in use and it shouldn't matter if it was.
In the case of INSERT, there are two kinds of errors from NODE%, a
general failure of the JSYS and an incomplete insertion.?? The error is
from the second case.? Unfortunately, SETNOD isn't reporting enough
information about the error, so I have to make some changes there.? It's
also possible that SETNOD is building an inconsistent database for the
monitor to swallow; at least the LIST command is giving me some odd
results, viz:
SETNOD>list arEA 2
[AREA 2]
A2RTR
TOTAL NODES FOUND: 1
SETNOD>
That's clearly wrong, viz:
!i dec
?Local DECNET node: VENTI2.? Nodes reachable: 7.
?Accessible DECNET nodes are:??? A2RTR??? BOINGO LEGATO???
TOMMYT??? VENTI2??? VENTI??? ZITI
The Exec output should probably be changed to say, "Nodes reachable in
local area" and "Online nodes in area are:"
Anybody have any ideas?? Hunches?? Clues?
------------------------------------------------------------------------
File 1) OLDF:[4,120]??? created: 1241 15-Apr-21
File 2) NEWF:[1,1]????? created: 0102 30-Apr-21
1)1???? set nod 44.9 name OSMIUM
****
2)1???? set nod 2.292 name OSIRIS
2)????? set nod 44.9 name OSMIUM
**************
1)1???? set nod 13.3 name RED
****
2)1 *set nod 2.298 name REACH *
2)????? set nod 13.3 name RED
**************
1)1???? set nod 2.298 name RSX11M
1)????? set nod 1.306 name RSX124
****
2)1???? set nod 1.306 name RSX124
**************
1)1???? set nod 42.5 name SPARKY
****
2)1???? set nod 2.291 name SPARK
2)????? set nod 42.5 name SPARKY
**************
1)1???? set nod 2.299 name THEPIT
1)????? set nod 35.70 name THOMAS
****
2)1???? set nod 2.299 name THEARK
2)????? set nod 35.70 name THOMAS
**************
I don?t know if Jon Newton is in this group, but he pointed me to this t-shirt that may be of interest.
https://curiousmarcs-store.creator-spring.com/listing/VAXinated?product=211
---
Supratim Sanyal, W1XMT
39.19151 N, 77.23432 W
QCOCAL::SANYAL via HECnet
> On Apr 22, 2021, at 5:31 PM, Dave McGuire <mcguire at neurotica.com> wrote:
>
> ?On 4/22/21 4:42 PM, Robert Armstrong wrote:
>>> Dave McGuire <mcguire at neurotica.com> wrote:
>>> .... schmutz in the slots.
>>
>> That's what you get for jimmying the cover interlock :)
>
> Heh. :) But, ah, no. We have everything as close to "as-shipped
> perfect" as possible at the museum, and even in a personal setting I'm
> WAY too anal to run a machine without proper covers.
>
> But when a BA32 sits in a dirty warehouse for twenty years, dust and
> crap gets into those slots, top covers or not.
>
>> The ZIF slots, "no cables attached to the cards" and the "identical POST pass/fail LEDs on every card" features of BI are nice for working on, but it's a real problem for restoration. Anything that attached to some peripheral (DEBNT, KLESI-B, KDB50, DMB32, etc) required a special "transition header" that adapted the backplane to the cable set for that particular device. Spare BI cards are fairly easy to come by, but everybody has thrown away the transition headers and the cards are pretty much useless without them.
>
> Yes, it's awful. I have countless BI and XMI boards with no cab kits.
>
> DEC was clearly not planning properly for the surplus and aftermarket
> for their machines. ;)
>
> -Dave
>
> --
> Dave McGuire, AK4HZ
> New Kensington, PA
Is there a Windows utility that will read and write RT11 files from TU58,
RX01/2 or RL01/2 images? A Linux utility would be OK too.
I know about PUTR, but it doesn't appear that it can run under any recent
(e.g. 64 bit) version of Windows..
And EXCHANGE on VMS works fine, but getting the image files on VMS in the
first place is a hassle.
Thanks,
Bob
With what was going on about RT11, I showed a much younger colleague some of the conversations on this list.
Let?s just say that I fear for the future of the human race.
Keith
For anyone running PyDECnet, I would recommend you update to the latest
version (582), since that removes a behavior that triggered BQTCP to
sometimes automatically block PyDECnet hosts.
And of course, it you're running something way older, there are probably
other improvements you'll also benefit from.
And thanks to Paul Koning, who wrote this nice piece of software.
Johnny
--
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
Ok, this is a bit of an off the wall question, but - can Task Builder (aka
TKB) build paper tape images in absolute loader format? Can anybody clue me
in as to the magic switch(es) to do this?
Thanks,
Bob
MIM::DECNET.TXT states that area 63 is "Reserved for hidden area testing". Is area 63 routing suppressed by PyDECnet and/or any other methods of connecting to HECnet? If one were to play around with local nodes in area 63 without remembering to bring down the upstream HECnet connection, what would happen?
I am interested in creating some useful semi-turnkey SIMH VAX instances to share with friends who are interested in playing with VAXen and/or connecting to HECnet, but are hesitant because of the learning curve involved. I figured it might be desirable to set up the simulations to use nodes in area 63 by default. I'll naturally want to test out intercommunication with my other simulations and real VAXen, and I'd like to understand whether I need to shut down my PyDECnet connection to HECnet while I am doing that.
--
Mark J. Blair, NF6X <nf6x at nf6x.net>
https://www.nf6x.net/
Time for a new release announcement of TCP/IP for RSX-11M-PLUS.
This is version 2.6 of BQTCP/IP.
It's been five months since the last official update, and there been
various smaller improvements.
Highlights:
. Improved TCP performance.
. Bugfixes in DNS subsystem.
. Fixed various MAIL bugs that caused issues.
. Improved MAIL performance, handling and features.
. Added EPSV and EPRT to FTP and FTPD.
. Improved TELNETD performance.
Detailed information on things that have been done since the last release:
TCP:
. In TCP, Change IO.REJ to create a socket in Time Wait, so that we
don't get multiple requests for something we reject.
. Improved TCP congestion window handling.
. Improved TCP retransmit recovery logic.
. Correct TCP slow timer handling. If KAF is active, cancel timer.
. Improve TCP sender. If the only thing motivating a send is a window
update, we always delay it.
. Added not starting new processes if pool is low.
. Changed TCP PU.RXP option to always return partial data, independent
of push flags.
DNS:
. Bugfix for resolver. If DNS resolving results in multiple answers,
the resolver only handled the first answer correctly.
. Bugfix for resolver. If a DNS response is received, which has an
empty answer section, that is also an answer.
. Improve resolver cache. If we get multiple identical answers,
only cache one copy.
TELNET/TELNETD:
. Added timeout to telnetd console logging I/O.
. Changed TELNET server to delay small sends.
. Improved telnet server to not set push on data sent.
. Improved telnet client to use PU.RXP when in binary mode.
. Improved telnet client. If connecting to something else than port 23,
assume we don't do telnet negotiations. However, if remote side
start
doing them, we will also start doing them.
FTP/FTPD:
. Added EPRT and EPSV handling to FTPD. Improve EPSV handling in FTPD.
MAIL:
. Improved mail reader screen handling.
. Fix MAILD to remove temporary files if connection is dropped.
. Improved MAILD SMTP receive parsing.
. Fix various priv issues in mail reader causing notification problems.
(Bugs reported by Kevin Jordan)
. Added mail label handling in mail reader.
. Bugfix in mail. FILE command filed wrong mail.
. Added better handling of locked records in mail.
. Improved mail submission processing to not wait until
mail actually delivered before returning status.
. Improved performance in adding mails to a mailbox.
IPNCONFIG:
. Updated IPNCONFIG.CMD for managing DECnet over IP connections.
Contributed by Oleg Safiullin
NETSTAT/RMD:
. Changed port lists in RMD and NETSTAT to not include local address
by default.
. Change TCP state texts. Previous LISTEN is now ACCEPT.
Previous SERVER is now LISTEN.
BQTLIB:
. Bugfix in BQTLIB. BP2 multiple IO code could misbehave.
Some additional notes:
As usual, I would recommend people to update as soon as possible.
The changes are not critical, but will lead to a much better experience.
For the RSX fixes to be applied, it is necessary to answer yes to the
question about installing RSX patches. Otherwise those fixes will not
be installed. This does not lead to any failures, but it might lead to
some components not running exactly the way you might be expecting (such
as daemons running under the wrong user).
As usual, the distribution is available from:
ftp://mim.update.uu.se/bqtcp.dsk
ftp://mim.update.uu.se/bqtcp.tap
ftp://ftp.update.uu.se/pub/pdp11/rsx/tcpip/tcpip.dsk
!!! BQTCP is also available through RPM !!!
(As an additional note, I have become aware of that there is some device
proxying access to the ftp service at Mim. This might lead to failure to
transfer large files. If you observe such problems, try connecting to
Mim at port 10021 instead, which is an alternative port for the ftp
server, and which circumvents the proxy.)
The documentation is also available through ftp on Mim, or also at
http://mim.update.uu.se/tcpipdoc
I hope people find this update useful.
Johnny
--
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
Hi,
I might have posted this to just Paul and Johnny but it's probably good for a bit of general discussion and it might enlighten me because I often have a lot of difficulty in separating the layers and functionality around tunnels of various types, carrying one protocol on top of another.
I use Paul's excellent PyDECnet and about half the circuits I have connecting to others consist of DDCMP running over UDP. I feel as though there's something missing but that might be misunderstanding. A DDCMP packet is encapsulated in a UDP one and sent. The receiver gets it or doesn't because that's the nature of UDP. I'm discovering it's often the latter. A dropped HELLO or its response brings a circuit down. This may explain why there's a certain amount of flapping between PyDECnet's DDCMP over UDP circuits. I notice it a lot between area 31 and me but but much less so with others.
In the old days, DDCMP was run over a line protocol (sync or async) that had its own error correction/retransmit protocol, was it not? So a corrupted packet containing a HELLO would be handled at the line level and retransmitted usually long before a listen timer expired?
Are we missing that level of correction and relying on what happens higher up in DECnet to handle missing packets?
I'm having similar issues (at least on paper) with an implementation of the CI packet protocol over UDP having initially and quite fatally assumed that a packet transmitted over UDP would arrive and therefore wouldn't need any of the lower level protocol that a real CI needed. TCP streams are more trouble in other ways.
Just some thoughts
Keith
