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

[Ethan Dicks]

On Fri, Jul 15, 2016 at 10:44 AM, Swift Griggs <swiftgriggs at gmail.com> wrote:
> 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.

Indeed.  As you've seen, I use both.  No need to be all "Commodore vs
Atari" about it.  ;-)

>> 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?

I mean vs ethernet-type networking.  The physical layer stuff has
fewer variants to worry about with Ethernet vs serial (3mbps vs 10mbps
vs 100mbps, and 10Base5 vs 10Base2 vs 10BaseT vs flavors of fiber as
opposed to all the parameters one has to match up to get any two
machines talking over a serial link).

Where this matters is that all our modern gear was developed in an
environment where nearly everything being transported across it is
TCP/IP.  Try pushing DDCMP over the wire.  ISTR there's now some TCP
wrappers to get gear to be willing to handle these packets, but that
just adds to the complexity and frustration.  With serial DDCMP, we
just hooked up two sync serial ports up with a modem eliminator (which
provides the baud-rate clocking for both hosts) and it "just works"
(since there are few options to configure at that point).  All the
configuration is a layer or two up as you set up the logical nodes in
your network.  Entirely unlike TCP/IP and Unix networking in terms of
workflow and type/quantity.

This is not a "A is better than B" argument - it's just some
descriptions of the elements of the process and how they are
different.

>> 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.

Sure.  Absolutely no argument.  Just pointing out that comparing DCL
to shell isn't exactly apples-to-apples either.  If anything, measured
in arbitrary units, DCL is a half-step over shell scripting and a
half-step below Perl (etc.) scripting.

> However, you don't have as many opportunities to write line-noise
> in DCL (joke!).  :-)

Have you ever seen a string of ''' used to dereference DCL args?
Definitely the hardest thing about getting a working complex DCL
script.

>> 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'.

I don't mean file permissions, I mean system privileges.  Some UNIX
filesystems have ACLs (VMS has _very_ well developed ACLs, but that's
not what I mean).  I mean "I am root" or "I am not root" in UNIX land
becomes, "what system object/resource do you wish to access?  Read or
write?  Do you have one of the following privileges: NETMBX, TMPMBX,
GROUP, GRPPRV, ACNT, ALLSPOOL, BUGCHK, EXQUOTA, GRPNAM, PRMCEB,
PRMGBL, PRMMBX, SHMEM,ALTPRI, AUDIT, OPER, PSWAPM, SECURITY, SYSLCK,
WORLD,DIAGNOSE, IMPORT, MOUNT, SYSGBL, VOLPRO, READALL,BYPASS, CMEXEC,
CMKRNL, DETACH, DOWNGRADE, LOG_IO, PFNMAP, PHY_IO, READALL, SETPRV,
SHARE, SYSNAM, SYSPRV, UPGRADE?

Want to mount a disk?  In Unix, a user is told "must be root".  In
VMS, you need MOUNT.  You can give someone MOUNT and none of the other
privs, meaning this user can mount disks or tapes but not necessarily
read physical memory or bypass file permissions or write to device
registers or any of the other privileged tasks.  It's not
all-or-nothing; you grant the level of access required and no more.

(http://www.mi.infn.it/~calcolo/OpenVMS/ssb71/6015/6017p014.htm#vms_privileges_tab)

>> 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.

Yes.  That was one I just dodged.  If stuff I was porting did a
fork(), I just found something else to port instead.  The workarounds,
as you point out, are non-trivial and don't map 1:1 to what fork()
does.

-ethan