DECnet Isn't Dead

Ronald Dumsfeld writes "The odds of folks under the age of 25 on Slashdot having heard of DECnet are pretty slim. This article over at Datamation gives some insight into people who've not given up on it. Poke around and find the documentation for the OSI-compliant version, or download the Linux version of the older DECnet IV and bask in the Security Through Obscurity."

Comments

TCP/IP license fees?

[ZiZ]

From TFA:

IP, though, is the industry standard protocol. These days, everybody knows how to use TCP/IP. That means anyone also deploying DECnet has to license both protocols. The good news is that the DECnet fees are a bit less than those for TCP/IP.

Did I miss something? So far as I know, the specifications for TCP, IP, and (most) assorted support protocols are openly avaliable, free of charge to implement, screw up, use and abuse. Is this suggesting DECnet fees involve someone paying you to use it? If that's the case, sign me up!

Of course it isn't dead!

[CyricZ]

DECnet is often used these days for very mission critical applications. The firm I work for uses DECnet because it is the easiest and most reliable way for us to maintain our VAX and Alpha clusters. Indeed, it is by far the most superior form of networking out there for applications where the uptime must be literally 100%.

We have had sales reps from various vendors come and suggest moving to a Windows 2003/PC setup (HAHA!) or towards a more UNIX/Linux-based setup. But we will stick with our DECnet-based VAX and Alpha clusters because they are known to work, and they work pretty damn well! But that's because it is amongst the finest of DEC engineering. That's the sort of engineering you just don't find these days.

Re:Of course it isn't dead!

[kerrle]

Oil Refineries.

The Valero refinery down here uses VAX machines to monitor the gauges on the equipment all over the plant.

Think about it - refineries don't have "downtime"...pretty much ever. Even when they're doing work on one part of the plant, the rest keeps going.

And they can't miss data - for both safety and environmental reasons.

Re:Of course it isn't dead!

[dr_dank]

Amen.

When I started college, my school had a vax mainframe that was slowly being phased out (the campus terminals were completely replaced by PCs about a year after I graduated).

The VAX was always up and was a reliable connection for me and my hand-me-down 286 running Kermit over a simple serial connection to the ethernet jacks in the dorm rooms. While my floormates were figuring out ethernet or the SLIP/PPP connections, I had a solid connection from the first day, a good counter to the guys ribbing me about my "text based internet".

VAX phone was a fun way to talk to people around campus before AIM became popular and the VAX went the way of the dodo.

Off topic, I know, but the parent brought back some memories.

Re:Of course it isn't dead!

[HiyaPower]

And what have you bought for all those "moore generations"? Some graphics interface and lots of insecurity with the present software that runs on them.

The question is not one of the hardware. I dare say if you wished, you could probably shoehorn OpenVMS into any processor you felt like providing it had some of the appropriate hardware protection. The demand is not there, so it hasn't been. People are much more likely to want to catch the virus de jour than have a problem with the version number on the operators log turning over on itself because of the continued uptime. Of course, finding somebody that knows Bliss-32 might not be the easiest in the world anymore.

There is a difference between old processors and operating systems and software that work. Please do not confuse them. There is a good reason that Nasa and a lot of the mission critical people are not "state of the art" when it comes to some of their software/hardware. Simply put, it needs to work, no ifs, no ands, no buts.

Re:Of course it isn't dead!

[VAXcat]

To really see how much better it is, you'll need to use it to get a feeling for what it can do. For one thing, there's the seamless integration with everything...if I wanted to copy a file in a DECnet network, I don't start a program like FTP, I just put a node spec in front of the filename, and use the normal COPY command like I do for local files. Similarly, while programming, if I want to open a file on another machine, I don't have to be running NFS or any program of its ilk...I just had the node spec to the filename in the OPEN statement.

Re:Of course it isn't dead!

[Arctic Fox]

I didn't think DECnet was responsible for logicals. I thought that was the file system... Give me logicals, VMSish symbols and most importantly, file versioning on another OS..... NOW we're talking....

Double Wow!

[richieb]

I remember installing DECnet on a couple of PDP-11/70s. Back in the Jurassic era of computing. And then writing some networking code in Pascal....

Sign me up! I'm making the switch!

[borkus]

To an operating system with TCP/IP, DECNET, IPX and SNA support -

OS/2

In the early 90's, if you wanted, you could get OS/2 to load a whole pile of transport protocols - which was pretty much necessary for the alphabet soup that ran client-server apps back then. In fact, Doom ran on IPX/SPX before it ran in TCP/IP.

Choice..

[wfberg]

Quoth TFA: Further, there are certain capabilities present in DECnet that have never evolved in TCP/IP. These include transparent remote file access, session management and validation, and integrated system management access.

Yes, TCP/IP has not evolved these layers at all. In stead, TCP/IP users are forced to accept that TCP/IP only provides reliable socket-based bi-directional streams of data routed world wide. Meanwhile in stead of being comfortably locked into a proprietary system, they face the challenge of choosing which applications to use to manage their sessions, presentation and file transfer.

HTTP(S), WebDAV, (S)FTP, SSH, SOAP, JMS, BXXP, XMPP, RTSP, SIP, NFS, SMB, NNTP, IMAP, etc. etc. And all of these protocols come with their own strengths and weaknesses! Worse, you could even swap TCP/IP out from underneath some of these protocols in favor of, for example, IPv6 or in some cases even an old dinosaur like NetBIOS.

To make matters worse, all these protocols come with easy-to use APIs, libraries, executable tools and even multi-vendor support, so far as to even be integrated into development environments such as "Java" or "Perl"..

The obvious drawback of this is of course that relying on these, for the most part, "open standards" makes it easier for your software to interoperate and be compatible across platforms and networks.

Next article written by Captain Obvious; "Many enterprises using Windows file sharing to replicate mission-critical information across Windows systems."

(Not that there's anything wrong with being lazy and using the OS' default transparant network thingamajig.. But that's not exactly winning on merits)

Now, if any one has any information as why DECnet is (supposedly) so much more robust and dependable than TCP/IP (especially DECnet-over-IP), I'd like to hear it. Does it use error correcting codes? Does it have some sort of secDNS equivalent (or even an analog to secure BGP? that would be kinda neat).

Re:Wow

[Oculus Habent]

I am 25, and were it not for random chance, I wouldn't know anything about DECnet. Until the the MicroVAX 3500 at work lost its boot drive in a power outage - 1.5 months ago - we actively used DECnet; The VAX primarily served software images to DECservers, which our old HP-UX server did most of the communication. I still have the hulking pair of RA81 behind me. We had several DECwriter III (LA120) paper-feed terminals that we used as wide-carriage impact printers for shipping documents and labels, and two large Line Matrix greenbar printers.

During the transition and move (all obtained from a previous company) several pieces stopped working. As I understand it, they'd been robbing pieces right and left to keep what was working still working. I poured through manuals as old as I am, and dug up default passwords. Thankfully, they weren't exactly security-conscious.

Anyone want a MicroVAX? You pay shipping. :)

Telenet

[ImaFraud]

Let's not forget about the old X.25 Telenet network which is still publicly accessible. A few years back myself and a friend of mine wrote an NUA scanner to poke around Telenet and see what's out there. We were awfully surprised to see that there were many systems still openly accessible. Not only that but we also found that there were a plethora of freely available PADs in most major cities. At one point we had compiled a list of several hundred of these numbers and methodically began mapping out large portions of the network. I would fully recomend those who are interested in arcane forms of networking to dig into this a little further. You may be pleasantly surprised.

Use VMS if you like shell scripting in FORTRAN

[emil]

While Dave Cutler (perpitrator of a great many OS atrocities) once remarked that "UNIX is a junk OS designed by a committee of PH.D.s," his operating systems have some profound problems.

Can anyone argue that VMS DCL has evolved as much as the Bourne environment? I believe it was Dennis Ritchie who severely criticised VMS for integrating most of the command interpreter into the kernel (which Cutler again did by moving many drivers from Ring 3 to Ring 0 in NT - same mistake?).

Yes, VMS has awesome capability in clustering and security, far outpacing most past and future implementations, but much of it has evolved about as far as JCL in becoming a modern system.

Lots of things just simply can't be done on VMS. UNIX is much more of a "happy medium" and has proven to be highly adaptable.

100% uptime ... oh please ...

[Bwah]

The projects I've worked for the last 8 years or so have used VAX and Alpha VMS and I can say that the much-vaunted uptime for VMS tends to be exaggerated. Yes VMS is generally solid, that I won't argue. However, it is very vulnerable to HW failure, just like anything else, and maybe more so than anything else we have around. We have had many many instances of a rogue VAXStation or microVAX taking out an entire cluster, redundancy and all. I see that as unacceptable.

You might say it must have been a admin/config problem. Weeeellll maybe (those guys seem to really know their sh-t cold, but one never knows) but then if it's that easy to misconfigure, how reliable is it really? And have you ever tried FINDING people that can maintain this stuff?

Lately we've been migrating off to the wintel world (and to some SGI as well) and the uptime numbers really have not changed that much. Some windows services tend to go down more often than their VMS equivalent, but things are mostly the same. The only reason we have to keep VAXen around is legacy applications that would be very very hard to port off of VMS. Anyone who has ever had to convert a G-Float to an IEEE double in order to use old VAX centric data sets know what I'm talking about here ... bleh.