This runs over serial (DL, X.25, etc) or parallel links (DR something). So no Ethernet hardware. It predates that by quite a while. Marty Gentry wrote the Ethernet hardware handler (driver) but it was never used for DECnet. DECnet was cancelled right after he finished it.
-----Original Message-----
From: owner-hecnet at Update.UU.SE on behalf of Zane H. Healy
Sent: Wed 10/21/2009 10:36
To: hecnet at Update.UU.SE
Subject: RE: [HECnet] Next retro comms project?
At 6:55 AM -0700 10/21/09, Bob Armstrong wrote:
* DECnet for RT11. This is easier at least, because DEC actually sold
such a product, but I don't know if actual kits and documentation for it
still exists. In either case, I've got PDP-11s and PDP-8s that could be on
HECnet if they had networking software.
As many know finding a copy of this has been a goal I've had for a
*LONG* time. I know of one person that might a copy, but last I
heard, couldn't get to where the floppies were and didn't have time.
Keep in mind this doesn't run over Ethernet.
Zane
--
| Zane H. Healy | UNIX Systems Administrator |
| healyzh at aracnet.com (primary) | OpenVMS Enthusiast |
| MONK::HEALYZH (DECnet) | Classic Computer Collector |
+----------------------------------+----------------------------+
| Empire of the Petal Throne and Traveller Role Playing, |
| PDP-10 Emulation and Zane's Computer Museum. |
| http://www.aracnet.com/~healyzh/ |
re: 2.11bsd DECnet
Performance will be horrible, and it will also probably be very problematic
Not clear whether you mean that in general, or just about the entirely
userspace version.
I don't think a completely user space DECnet implementation is even
possible on a PDP-11 but I don't see why a kernel-integrated version
couldn't be done. 2.11bsd already has TCP/IP networking that works
perfectly well. It's not super fast, but then a PDP-11 (at least if we're
talking about real ones) isn't a super fast machine either. The TCP/IP
speed is on a par with the performance of the rest of the system. We'd
probably have to replace the TCP/IP networking in the kernel with DECnet
because of address space limitations, so it'd be a kernel build choice for
either TCP/IP networking OR DECnet, but I think most people could live with
that.
Bob
I forgot about the SNA product for Windows NT 3.51/4.0. I have a couple of those kits hanging around. I don't have the SNA hardware but I do have the software.
Any takers? I certainly don't need them?
-----Original Message-----
From: owner-hecnet at Update.UU.SE on behalf of Jason Stevens
Sent: Wed 10/21/2009 10:33
To: hecnet at update.uu.se
Subject: Re: [HECnet] Next retro comms project?
Microsoft SNA server works pretty well for that, and it's easy to find...
Many moons ago I had TONNES of machines setup in that kind of manner, with
type 1 token ring to boot! (4mbit).
Even with Windows NT 3.51 & 4.0 it worked surprisingly well. (SNA Server 2.x
was waaay better then 3.x & 4.x IMHO). Anyways it was easy to connect the
tokenring to the FEP, but later on we got cisco routers that would do
translational bridging and local ack so we moved our SNA servers to
ethernet only.. Just remember to flip the bits of the FEP address as the
endian is different from ethernet to tokenring.
I've also done the netware SNA gateway, but it was living hell to setup... I
doubt I could get it to work again...
On Wed, Oct 21, 2009 at 10:26 AM, Fred <fcoffey at thrifty.misernet.net> wrote:
On Wed, 21 Oct 2009, Sampsa Laine wrote:
I thought SNA mostly ran on Token Ring or something?
I have an IBM PS/2 model (something) with both an MCA Token Ring card and
and MCA Ethernet - and I even have a passive Token Ring Mau! (and a cable,
somewhere ...)
Now if I could just find that gateway software. When I had access to a
real mainframe, all of the PC's went through a handful of these PS/2's via
Ethernet, and the PS/2's had token ring cards in them connected to a real
FEP.
Fred
At 6:55 AM -0700 10/21/09, Bob Armstrong wrote:
* DECnet for RT11. This is easier at least, because DEC actually sold
such a product, but I don't know if actual kits and documentation for it
still exists. In either case, I've got PDP-11s and PDP-8s that could be on
HECnet if they had networking software.
As many know finding a copy of this has been a goal I've had for a *LONG* time. I know of one person that might a copy, but last I heard, couldn't get to where the floppies were and didn't have time. Keep in mind this doesn't run over Ethernet.
Zane
--
| Zane H. Healy | UNIX Systems Administrator |
| healyzh at aracnet.com (primary) | OpenVMS Enthusiast |
| MONK::HEALYZH (DECnet) | Classic Computer Collector |
+----------------------------------+----------------------------+
| Empire of the Petal Throne and Traveller Role Playing, |
| PDP-10 Emulation and Zane's Computer Museum. |
| http://www.aracnet.com/~healyzh/ |
At 2:41 PM +0100 10/21/09, Sampsa Laine wrote:
Old-school (68K) Macs: I don't know where I got this idea but I think there might be a PATHWORKS client for classic Macs? Anybody ever use it?
I think there was a *VERY* old client. Plus the company that did classic Samba support also did DECnet support, IIRC. For many years I ran the Appletalk server on my Alpha. I had to give that up so I could move to OpenVMS v8.3 and Mac OS X 10.4.x. :-( I *REALLY* miss the classic Appletalk support, as it worked *REALLY* well.
Zane
--
| Zane H. Healy | UNIX Systems Administrator |
| healyzh at aracnet.com (primary) | OpenVMS Enthusiast |
| MONK::HEALYZH (DECnet) | Classic Computer Collector |
+----------------------------------+----------------------------+
| Empire of the Petal Throne and Traveller Role Playing, |
| PDP-10 Emulation and Zane's Computer Museum. |
| http://www.aracnet.com/~healyzh/ |
Microsoft SNA server works pretty well for that, and it's easy to find...
Many moons ago I had TONNES of machines setup in that kind of manner, with type 1 token ring to boot! (4mbit).
Even with Windows NT 3.51 & 4.0 it worked surprisingly well. (SNA Server 2.x was waaay better then 3.x & 4.x IMHO). Anyways it was easy to connect the tokenring to the FEP, but later on we got cisco routers that would do translational bridging and local ack so we moved our SNA servers to ethernet only.. Just remember to flip the bits of the FEP address as the endian is different from ethernet to tokenring.
I've also done the netware SNA gateway, but it was living hell to setup... I doubt I could get it to work again...
On Wed, Oct 21, 2009 at 10:26 AM, Fred <fcoffey at thrifty.misernet.net> wrote:
On Wed, 21 Oct 2009, Sampsa Laine wrote:
I thought SNA mostly ran on Token Ring or something?
I have an IBM PS/2 model (something) with both an MCA Token Ring card and and MCA Ethernet - and I even have a passive Token Ring Mau! (and a cable, somewhere ...)
Now if I could just find that gateway software. When I had access to a real mainframe, all of the PC's went through a handful of these PS/2's via Ethernet, and the PS/2's had token ring cards in them connected to a real FEP.
Fred
I'm not ready to part with it just yet. Sorry...
-Steve
-----Original Message-----
From: owner-hecnet at Update.UU.SE on behalf of Jason Stevens
Sent: Wed 10/21/2009 10:08
To: hecnet at update.uu.se
Subject: Re: [HECnet] Next retro comms project?
Would you be willing to sell it?
On Wed, Oct 21, 2009 at 10:04 AM, Steve Davidson <jeep at scshome.net> wrote:
I have a copy of PATHWORKS for MAC. It includes a DECnet client.
Haven't used it for years though...
-Steve
-----Original Message-----
From: owner-hecnet at Update.UU.SE on behalf of Sampsa Laine
Sent: Wed 10/21/2009 09:41
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Next retro comms project?
More ideas I just thought of:
Amiga - I've got a DECNET package here for my Amiga, unfortunately the
license key only works with one node address - and I naturally have no
idea what that address is. I'll have a play once my Amiga is up and
running again though, the product looks pretty full-featured (comes
with MAIL, CTERM and file transfer client and server).
Old-school (68K) Macs: I don't know where I got this idea but I think
there might be a PATHWORKS client for classic Macs? Anybody ever use it?
Sampsa
On 21 Oct 2009, at 14:31, Steve Davidson wrote:
SNA can run on multiple physical transports using the gateways.
Serial, X.25, network adapter (specialized), etc are available. The
SPD's specify what is supported. Like Johnny said however, finding
some of this hardware may be a problem. One of the SPD's mentions
an intermediate server that I have never seen/heard of.
Sort of reminds me of the fun and games (not to mention expense) to
get
SNA to talk to Netware.
-Steve
-----Original Message-----
From: owner-hecnet at Update.UU.SE on behalf of Sampsa Laine
Sent: Wed 10/21/2009 09:27
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Next retro comms project?
I thought SNA mostly ran on Token Ring or something?
On 21 Oct 2009, at 14:24, Johnny Billquist wrote:
There was a SNA product for RSX as well. Don't know if it required
special hardware as well.
But I very much doubt anyone will be able to find that now
anyway. :-)
Johnny
Steve Davidson wrote:
It can via the gateway software. I see several and it appears that
many
(if not all) require specialized hardware for the
interconnection. A
search for (vms sna gateway) will point you to the SPD's.
-Steve
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE]
On
Behalf Of Sampsa Laine
Sent: Wednesday, October 21, 2009 08:34
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Next retro comms project?
Can VMS talk SNA? If so, I'm in :)
Sampsa
On 21 Oct 2009, at 13:31, Fred wrote:
On Wed, 21 Oct 2009, Sampsa Laine wrote:
Where should we go from here? Setting up our own virtual X.25
PSDN tunnelled over IP maybe? Something crazy with SNA?
SNA! SNA! :)
I could set up Hercules here running MVS 3.8J ... ;) I'm sure
the folks have been able to get SNA to work within the emulator.
I set up Hercules and MVS once, but other than a novelty, I
really didn't do much with it, because most of my associates
wouldn't know a mainframe if it ran them over. I think it would
be interesting to get something quasi-public (on HECmet) going.
Fred
----
Lets call it for what it is - "legacy" is a term that people use
in a
polite but derogatory manner to imply that the future direction
they
prefer is not that which they view as the current direction.
<winmail.dat>
On Wed, 21 Oct 2009, Sampsa Laine wrote:
I thought SNA mostly ran on Token Ring or something?
I have an IBM PS/2 model (something) with both an MCA Token Ring card and and MCA Ethernet - and I even have a passive Token Ring Mau! (and a cable, somewhere ...)
Now if I could just find that gateway software. When I had access to a real mainframe, all of the PC's went through a handful of these PS/2's via Ethernet, and the PS/2's had token ring cards in them connected to a real FEP.
Fred
Very true!
-----Original Message-----
From: owner-hecnet at Update.UU.SE on behalf of Johnny Billquist
Sent: Wed 10/21/2009 10:17
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Next retro comms project?
Sampsa Laine wrote:
On 21 Oct 2009, at 14:55, Bob Armstrong wrote:
Well, if we're going to go off into Wishful Thinking Land here :-)
* DECnet for BSD, especially 2.11 PDP-11 bsd. Yes, a 16 bit version is
significantly harder than a 32 bit version, I know, but there are several
real PDP11s out there running BSD that could be on HECnet. I know - I've
got one! We could use the Linux DECnet as a starting point - the dn
userspace utility programs might not even be that hard to port - but we'd
need a kernel wizard to do the tricky bits :-)
Just an idea, and I'm not a network programming guru at all, but do we
really need to have stuff in the kernel? Could we not just have a
userland process that writes frames to the network interface* and then
apps talk to the server process? I imagine this is easier to both write
and debug...
Sampsa
* assuming we are able to write raw frames to the net interface of
course...
Performance will be horrible, and it will also probably be very
problematic. You also need some sort of a transition point between the
kernel and user space to even start doing this. Any user process who
would like to talk DECnet will either want to do system calls, or open a
device to do the communication. That system call, or device will then
access the memory area of the user process to read/write data from the
user process. If your protocol implementation also were in user space,
you then need to send it back from the kernel back into userspace again,
for the protocol process. And you also need to keep track of the
original user process, to keep a connection living, and you need to know
if the user process goes away, so that you can tear down stuff when it
happens. There are a lot of headaches in there, and having a user
process doing it isn't really that helpful.
It's a common mistake to think that this will actually be easier just
because the protocol is implemented as a user space process. It isn't.
The only thing that becomes easier is that once the basic framework is
in place, you can more easily install and remove the code that
implements the protocols. But since buggy protocol implementations often
corrupt more than can be fixed, you often end up needing to reboot anyway.
And we still have the horrible performance issues...
Johnny
Sampsa Laine wrote:
On 21 Oct 2009, at 14:55, Bob Armstrong wrote:
Well, if we're going to go off into Wishful Thinking Land here :-)
* DECnet for BSD, especially 2.11 PDP-11 bsd. Yes, a 16 bit version is
significantly harder than a 32 bit version, I know, but there are several
real PDP11s out there running BSD that could be on HECnet. I know - I've
got one! We could use the Linux DECnet as a starting point - the dn
userspace utility programs might not even be that hard to port - but we'd
need a kernel wizard to do the tricky bits :-)
Just an idea, and I'm not a network programming guru at all, but do we really need to have stuff in the kernel? Could we not just have a userland process that writes frames to the network interface* and then apps talk to the server process? I imagine this is easier to both write and debug...
Sampsa
* assuming we are able to write raw frames to the net interface of course...
Performance will be horrible, and it will also probably be very problematic. You also need some sort of a transition point between the kernel and user space to even start doing this. Any user process who would like to talk DECnet will either want to do system calls, or open a device to do the communication. That system call, or device will then access the memory area of the user process to read/write data from the user process. If your protocol implementation also were in user space, you then need to send it back from the kernel back into userspace again, for the protocol process. And you also need to keep track of the original user process, to keep a connection living, and you need to know if the user process goes away, so that you can tear down stuff when it happens. There are a lot of headaches in there, and having a user process doing it isn't really that helpful.
It's a common mistake to think that this will actually be easier just because the protocol is implemented as a user space process. It isn't. The only thing that becomes easier is that once the basic framework is in place, you can more easily install and remove the code that implements the protocols. But since buggy protocol implementations often corrupt more than can be fixed, you often end up needing to reboot anyway.
And we still have the horrible performance issues...
Johnny
