VMS stability back in the day (was Re: NuTek Mac comes)

[Swift Griggs]

On Fri, 15 Jul 2016, Ethan Dicks wrote:
> It was a huge deal in the late 80s and into the 90s.  I was on both 
> sides, so mostly, I watched.

This thread has definitely been the most civil discussion and set of 
anecdotes I've seen when folks discuss VMS and Unix in the same thread. I 
usually don't bring up VMS because I'm not that well versed in it, and 
when I make one mistake in the nomenclature or some other triviality, 
someone usually gets butthurt and tries to make a fool out of me or just 
scream bloody murder. However, folks have been nice this time, for which I 
breathe a sigh of relief.

Of course there is still time for someone to troll... :-)

> I've written device drivers, system utilities, and application code for 
> both. 

>From your experience and depth on both platforms, it sounds like you have 
a well rounded perspective. I have merely hours of experience in VMS but 
years in UNIX. I've never written any device drivers outside of stubs or 
proof of concept stuff I've done in tutorials. However, I've written a lot 
of C utilities and app code and most of that was on UNIX platforms, but a 
little in DOS or on the Amiga.

> If I have choice, I'll grab something UNIXy to do my work on - I'm not 
> particular as to flavor.

I'll reach for NetBSD first, FreeBSD second, and then it's just "whatever 
will work" if those are off the table. For play, I love to work with 
obscure, obsolete, specialized, or otherwise interesting UNIX variants.

> How well do you think it would go if all you had was SLIP and PPP?

Do you mean versus some other point-to-point protocol or versus just using 
serial terminal emulation? If it's versus DECnet, I'd say that it'd go 
quite well. I've used both SLIP and PPP (and loads of others) to build 
networks with Unix boxes and/or Cisco routers. When I worked for Cisco I 
implemented a LOT of PPP links. They work great. They create a nice 
interface for you to apply ACLs, routing rules, etc.. I have zero problem 
with either. In fact, there are extensions to PPP such as multi-link and 
VJ compression that make it rock even harder. Personally, I've had 
super-wonderful experiences with the protocol. My only doubt is that if it 
was used on very old equipment it might have been too CPU or memory 
intensive versus something much more simplistic or efficient.

> All serial, all day.  We still got a lot done.

There isn't anything wrong with serial, as far as I'm concerned. It's got 
it's place and it did a great job for folks. It still does in many cases.

> That said, it was easier (to me) to write full-on apps and utilities in 
> DCL than sh or csh.

Well, I'm a C programmer, as I mentioned, as well as a UNIX zealot and I 
am pretty allergic to csh. Again, it's just a style issue, but I wish that 
Bill Joy didn't name it "csh" because it's not something I'm happy to see 
associated with C coders (folks automatically assume you want csh if 
you're a c-coder sometimes). I'll definitely take any form of Bourne shell 
(sh ksh zsh bash) before I resort to csh. Fortunately, most folks seem to 
agree and csh is pretty niche these days. That's not to say there aren't 
very enthusiastic users of csh, too.

As far as DCL goes, I'll just say this, without 'while' and 'for' I'm 
sorry, it's a PITA. As a programmer, I find shell scripting to be much 
more flexible due to more language features and sugar. Sure, you can use 
'if'-statements to cobble together a replacement for most situations, but 
it's clumsy & ugly from what I've seen.

> It would be a fairer comparison to develop a complex app in Perl vs DCL 
> (Perl would win, but it has a lot going for it).

Feature wise, I don't see much of a comparison. Perl would trounce DCL in 
a comparison involving functionality. It's not a fair fight or apples to 
apples in my mind at all. Plus, Perl isn't a CLI interpreter (though I 
suppose you could try it that way). DCL is. Hence, I'd compare it to shell 
script. However, you don't have as many opportunities to write line-noise 
in DCL (joke!).  :-)

> The regularity and predictability of args and options is definitely a 
> strength in DCL.  Args are entire words, not letters which change from 
> app to app.

That is the big thing that DCL has going for it, if you ask me.

> Next thing - how about those args to 'dd'?  Crazy.  Now how about 
> 'tar'... etc., etc.  I use this stuff every day, but I have internalized 
> a massive amount of UNIX trivia to be able to do so.

This is always the criticism of UNIX environments versus VMS & DCL. It's 
valid, I think. I agree with you about the whacky args to 'dd', 'tar', and 
others (SysV vs BSD 'ps', I could go on and on). 

> VMS requires far less random factoid knowledge to get stuff done on the 
> command line.  There's a system command line parser, and it helps with 
> the consistency.

I've also been told that the way the help is put together in VMS tends to 
make the CLI args and switches more consistently well-documented. That's a 
lesson for some clever UNIX variant to learn, or perhaps it's the "wild 
west" nature of UNIX that actually attracts some people. It's the whole 
"less regulation" idea, maybe. I don't know. However, I would like to see 
some improvements here and there. UNIX isn't perfect. There are plenty of 
dingy spots. However, to me it's like democracy - it's the best of a bunch 
of bad systems.

> Much stronger.  There are dozens of privileges you can grant so someone 
> can do their job and not overstep things.  UNIX says, "all or nothing.  
> Don't screw up."

Well, while I agree VMS is much stronger when we talk about it in the 
context of the 1990s. However, it's certainly not "all or nothing" even in 
older UNIX variants. There *are* 'group' and 'other' permissions, not just 
'owner'. The problem for that model is when you need an exception. Ie.. 
someone wants to write to a file that they don't own, aren't in the proper 
group for, and you can't add them to the group for some reason, PLUS you 
can't open up the file permissions. That's the the most common situation 
that serves as an argument for POSIX ACLs. It's the "textbook example". 
Having said that, let's talk real for just a sec. The current crop of Unix 
variants often have equal or better authentication/authorization systems. 
Take a look at SElinux, Cgroups, Capabilities, and POSIX ACLs. Put those 
all together and you can do everything that VMS can plus a ton more.

The modern discussion also mirrors the storage capabilities of VMS. It has 
has shadow-sets (essentially RAID1) for a long time and they nailed that 
functionality very early on as well as made the ODS file system aware of 
it. However, post LVM2, ZFS, BTRFS, DRBD / HAST, and/or compared to modern 
VxVM & VxFS, VMS is lacking a very long list of valuable and important 
features that are freely available now in many UNIX variants.

> OTOH, I learned a *lot* porting utilities and games from 
> comp.sources.unix and comp.sources.games to VMS.  Some things were a lot 
> harder than others.

I think the biggest stumbling block is the lack of fork() in VMS. They 
have threads and some hacks like LIB$SPAWN, instead. However, in most 
cases, I'll take a fork() model over threads any day. Concurrency and 
marshalling threads has always been a PITA, IMHO. It's not that fork() 
gets out of it, it just forces a more simple structure/design (again, just 
my opinion based on experience).

-Swift