I finally got my issues with Comcast straightened out and I now have static IP addresses. They are
IPv4: 50.185.8.122
IPv6: 2603:300b:6c4:21a0:c77b:4f58:27e4:6de2
These are also always available in DNS as decnet.theberrymans.com <http://decnet.theberrymans.com/>
Hopefully, this will be the last change for a while.
Mark Berryman
Area 27
I finished the auto-mounting code for Tops-20 DAP, viz:
NFT>*dir venti2::dsk*:<Help>units.hlp*
VENTI2::TOMMYT:<HELP>
UNITS.HLP.1;P777752 1 2210(7) 28-Apr-1980 17:23:03
VENTI2::TOPS20:<HELP>
UNITS.HLP.1;P777752 1 2210(7) 28-Apr-1980 17:23:03
NFT>
Over in FAL, one finds the following debugging output:
[Received Access message (Flg=LEN Cnt=30.)]
[Parsing Access message]
[DSK*: PS:<HELP>UNITS.HLP.1, JFN 7, Unit* High]
[Trying file TOMMYT:<Help>units.hlp]
[Assigned JFN 7, Unit* High]
.
.
.
[Trying file STAR:<Help>units.hlp]
[Failed. No such directory name]
[Mounted file structure TOPS20: on behalf of SLOGIN]
[Trying file TOPS20:<Help>units.hlp]
[Assigned JFN 7, Unit* High]
.
.
.
[Dismounted file structure TOPS20: on behalf of SLOGIN]
Like many things I do, I tend to have an overly optimistic if not naive
idea of the development involved and bump into edge cases. I had to
split DAPLIB up into three separate sources to accommodate the changes,
which kept getting longer as I found another case I hadn't considered.
The same thing happened in spades when I put NRT support into
Kermit-20. The changes were so pervasive that I started looking around
for regression tests. C-Kermit itself has wonderful scripting, which
you can even use to write a compiler. But not testing scripts, so I
wrote my own batch control files.
Anybody know what's available for DECnet; in particular, DAP? I seem to
remember there being something for UETP, but it wasn't extensive.
After I got done 'enough' with the auto-mounting code for FAL (meaning,
I didn't make the modifications to the access control job because I
bumped into .MSIMF), I turned to fixing a bug that I bumped into a few
years ago. While Tops-20 does not support wildcarding devices, it does
support wildcarding all structures that the system currently has online
via the DSK*: moniker.
So, let's say you're a 60+ who is having those occasional lapses of
memory and you /really/ can't remember a single thing about something
you think you might have somewhere. This is, of course, completely
forgetting that you wanted to find something in the first place... you
can ask the EXEC to do something like, DIRECT DSK*:<*>*SOMETHING*.*.0.
You can also hand that to FIND to have it look in all those files.
Some experimentation with NFT shows that Tops-20 FAL supports structure
wildcarding. BUT!! If you're being nosy or are just plain hacking and
do DIRECT DSK*:<*>*.*.*, it crashes with a GLXLIB out of memory error
(ASE, Out of Address Space)...
Researching this shows that Tops-20 DAPLIB tries to buffer messages
before dumping them over the wire and that the decision it makes to dump
is file count based. That appeared to not work properly because of two
issues. First, each file was actually generating four separate
messages: a Name, an Attributes, a Date/Time Attributes and a File
Protection Attributes. Second, the buffer builder was always allocating
a buffer for the maximum size message, 4090 characters (1032 thirty-six
bit words).
That's pretty excessive, considering the typical sizes. Some
instrumentation shows the below:
Message Allocated Actual %Excess
Name 4,090 18 99.56%
Attributes 4,090 17 99.58%
Date/Time 4,090 40 99.02%
Protection 4,090 7 99.83%
I changed the buffering algorithm to dump based on available memory.
The starting available memory is 448 pages, so I take ¾ of that to
devote to DAP buffers and ¼ (122 pages) to do the dumping. That fixed
the problem. Then I changed the memory allocation to trim unused words
from the end of messages. That's not working as well as I expected,
probably because I need compact (or 'burp') the memory. Another
alternative would be to build all messages in a single area and then
only allow a chunk in the linked list for what I need. No burping.
A concern is what happens with the Configuration BUFSIZ operator and
what to do if it is 0 (unlimited). The DAP specification specifies that
an operand of zero means that if one of the two systems has an
unlimited buffer size, it sends a 0 and the two systems will use the
nonzero buffer size as the maximum. If both systems send 0, there is no
limit on the length of messages which may be sent.
My question is whether zero is absurd. Does any implementation send that?
It probably doesn't matter that much for sending, but I'm also thinking
that I might hypothetically have a similar problem on receive.
Obviously I don't because the current Tops-20 DAP won't negotiate a size
larger than 4096 bytes. Is anything running larger than that? Would it
be silly to?
Hello, newbie here :)
I used to run OpenVMS 7.3 under simh on a Raspberry Pi, but have never learnt past the "newbie" stage about OpenVMS.
With the availability of the x86 Community Edition, I have now 9.2-1 running under Proxmox at home, and thought "maybe it's time to learn about DECnet and join the HECnet".
So here I am, with exactly 0 idea of how DECnet works but the intention to read some of the docs and figure it out enough to join a node or two (or more?)
Regards,
Alice
Much of my DECnet work involves either SIMH or PyDECnet, both of which can do Ethernet over UDP, with a Billquist bridge (or Python equivalent) providing the bridging. So while I've used TAP some years ago, it hasn't been a concern lately.
Then came the time to find an Alpha emulator to run VMS, and it turns out SIMH only has the skeleton of one, not even close to ready for real use. But there are others, and after some searching I landed on AXPbpx. That works well; VMS 8.4 installs on it without problems especially with some help from various Wiki pages. But the obvious complication is that its Ethernet emulation talks to an interface, not UDP (not as far as I can tell). So I looked for TAP as the way to do that since my laptop's physical interface (being WiFi) is not useable for the job.
Surprise: no more Tun/Tap for Mac OS. Or at most, something that's buried in a corner of some other package and at risk of being broken by Apple any day now.
But some Googling for options turned up something very simple that seems to work. Mac OS, in its network settings, lets you define a "virtual interface" bridge. A typical use for that is to share a physical interface, but it doesn't actually need to be connected to a physical interface to work. I tried that.
In System Preferences, Network, at the bottom left is a button bar with + - O, that last one a circle with some dots in it and a downarrow. Click that, last option is Manage virtual interfaces. It lists your bridges, if any. Click on + to add one, give it a name. It will show up in the virtual interfaces list with a Unix-style interface name like "bridge1".
Then you can connect things to that bridge, for example an AXPbox emulated Ethernet, or a PyDECnet circuit via pcap. Wireshark will happily display the packets on that bridged network. And a software bridge can then connect that LAN to other things, for example over UDP.
Enjoy.
paul
