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
Version 5.3(235)-5 incorporates all fixes since the major release of
5.3, Edit 230 in January of this year. These are as follows and can be
identified in the code with the edit number as the prefix of a comment.
<about:blank?compose#_Toc137380940>
[231] Fix RECEIVE with no file name
[232] 36 bit byte file sizes
[233] Transaction Log and Debug log fixes and enhancements
Transaction logging
Garbled Text
Write-Protection Failures
Enhancements
Debug Log Decode Fix
[234] Error messages may not be seen if displayed in remote server
[235] Properly signal and handle file errors in server mode
Additional Batch Tests
K2036P: Kermit-20 36 Bit Mode via pseudo-terminal
K2036C: Kermit-20 36 Bit Mode via pseudo-terminal with parity
Updated Help
All source, documentation, executables, control files and test data are
available for Anonymous NFT on HECnet from VENTI2::PS:<OINKY.K20MIT> and
associated subdirectories. Documentation includes more detail on the
above list. All regression tests have passed except for Tops-10 because
of some local networking issues.
Be aware that VENTI2:: is running a FAL alpha candidate, so let me know
if you get unexpected behavior.
Hi,
Is anyone testing this mailing list's recipients?
The reason I ask is:
06-02 00:07:58 NOREC SMTP OKBL DE 65.108.62.138:39112 cassini.dfupdate.se. 65.108.0.0/16 24940 HETZNER-AS, DE
06-02 00:07:59 NOREC SMTP OKBL DE 65.108.62.138:39112 cassini.dfupdate.se. 65.108.0.0/16 24940 HETZNER-AS, DE
06-02 00:33:06 NOREC SMTP OKBL DE 136.243.112.216:42384 static.216.112.243.136.clients.your-server.de. 136.243.0.0/16 24940 HETZNER-AS, DE
06-02 00:33:06 NOREC SMTP OKBL DE 136.243.112.216:42384 static.216.112.243.136.clients.your-server.de. 136.243.0.0/16 24940 HETZNER-AS, DE
06-02 00:34:26 NOREC SMTP OKBL DE 65.108.62.138:40994 cassini.dfupdate.se. 65.108.0.0/16 24940 HETZNER-AS, DE
06-02 00:35:02 NOREC SMTP OKBL DE 136.243.112.216:36476 static.216.112.243.136.clients.your-server.de. 136.243.0.0/16 24940 HETZNER-AS, DE
06-02 00:35:12 NOREC SMTP OKBL DE 136.243.112.216:36908 static.216.112.243.136.clients.your-server.de. 136.243.0.0/16 24940 HETZNER-AS, DE
06-02 00:40:02 NOREC SMTP OKBL DE 136.243.112.216:36476 static.216.112.243.136.clients.your-server.de. 136.243.0.0/16 24940 HETZNER-AS, DE
06-02 00:40:12 NOREC SMTP OKBL DE 136.243.112.216:36908 static.216.112.243.136.clients.your-server.de. 136.243.0.0/16 24940 HETZNER-AS, DE
06-02 00:45:56 NOREC SMTP OKBL DE 65.108.62.138:41946 cassini.dfupdate.se. 65.108.0.0/16 24940 HETZNER-AS, DE
06-02 00:57:11 NOREC SMTP OKBL DE 65.108.62.138:43082 cassini.dfupdate.se. 65.108.0.0/16 24940 HETZNER-AS, DE
Activity from cassini.dfupdate.se is valid and expected.
The other attempt(s) from static.216.112.243.136.clients.your-server.de was an attempted non-local relay to jessindewinter(a)gmail.com<mailto:jessindewinter@gmail.com>
It wasn't exactly a problem and the attempt was denied with some tar-pitting along the way.
Times in GMT+01:00 (BST) by the way.
Keith
Greetings all,
I'm performing a firewall replacement along with all kinds of other comms related tasks at my office today.
This means Area 35 will be up and down and possibly out for a few hours.
I'll be starting in the next 2 hours or so. All the work will be finished this afternoon.
Cheers, Wiz!!
Since there has been a bunch of work done to revive what is supposedly a DECnet Phase I implementation (DECnet/8 for RTS/8) I realized I could perhaps get some more information going back that far. Some months ago Nathan Brookwood (formerly known as Nathan Teichholz) gave a talk about the beginning of RSTS-11, and in that he mentioned as an aside that he subsequently served as program manager for the initial development of DECnet.
So I asked him if DECnet/8 sounded familiar and if he could tell me anything further about that time. His reply:
----------
I was responsible for coordinating all the versions of DECnet for the initial "Phase I" releases, but developers in each operating system were responsible for the implementations. Each group was building from the definitions of DDCMP and NSP that were extant in the 1973-75 period. There was also a testing and communications protocol called "NICE" (don't ask me what that stood for) and a file transfer utility.
The Phase I versions did not include routing, and when the developers tried to add routing capabilities to those first versions, they discovered that there was a need to make significant changes to NSP that would preclude backwards compatibility with the Phase I versions. The implementation of DDCMP survived intact, since physical link protocols are below the routing protocols level.
----------
That ties into the statement in the Phase III General Description document which says that Phase I nodes can't coexist with later versions in the same network, and it also matches what the DECnet/8 manual makes quite clear in its chapter discussing the protocol details: Phase I NSP is conceptually pretty similar to Phase II NSP, but the packets are 100% incompatible. So the "significant changes" Nathan mentioned are what happened in DECnet Phase II -- which modifies NSP to include sequence numbers and ACKs and in the process also changes lots of other details in the protocol encoding. That still wasn't quite enough, and Phase III filled in some missing details in an upward compatible fashion (the Connect Ack and Retransmitted Connect Initiate message, as well as timeout and retransmit algorithms).
paul
I've been testing my changes to Tops-20 NFT and ran into what what I
thought were some perhaps interesting results, viz:
NFT>*i twonky*
Attempting connection to TWONKY:: [31.37]
Maximum buffer size: _0!_
Operating System: Tops-10, File System: Tops-10
DAP: 7.0, DECnet: _0.0_
NFT>*i ostara*
Attempting connection to OSTARA:: [31.15]
Maximum buffer size: 4096
Operating System: Ultrix-32, File System: _13 (Unknown)_
DAP: 7.0, DECnet: 1.0
Note that I am clipping the capability display for these examples. By
"interesting", I was surprised to find that Tops-10 is reporting a
buffer size of zero, but more by it reporting a DECnet version of 0.0.
Where are these version numbers defined? For Ultrix, I would assume that
I need a more up-to-date list of file systems, given that the highest
that DAP 5.6 states is 9 for OS-8 (!!)
As a comparison, this is what I see for VENTI2:: (Tops-20) and a random
RSTS host.
NFT>*i*
Local Executor is: VENTI2:: [2.522]
Maximum buffer size: 4096
Operating System: Tops-20, File System: Tops-20
DAP: 5.6.1, DECnet: 2.0
NFT>*i pirsts*
Attempting connection to PIRSTS:: [29.205]
Maximum buffer size: 636
Operating System: RSTS/E, File System: RMS-11
DAP: 5.6, DECnet: 4.1
I want to sign on to MIM:: later to see what the RSX NFT client says;
it's certainly possible that I am not displaying this correctly.
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.
The RSX image that I created for simh (and thereby also the PiDP-11)
have just been enhanced a bit again.
Since it appears that HECnet is of some interest, I added a section in
the initial boot setup dialog to also configure DECnet-over-IP multinet
links.
So, if anyone wants this, all they need to do is answer a few questions
at initial boot (or whenever they manually run the config script), and
they will have a nicely setup RSX system, which also already connects
using DECnet-over-IP to wherever they want.
This is obviously not limited to HECnet. You can use this to setup links
between any DECnet nodes on any kind of network. HECnet is just one such
instance.
Information on the image can be found at http://mim.stupi.net/pidp.htm
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
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?
