Favorite operating systems query (UNIX vs VMS flaming!!!)

[Daniel R. Levy]

In article <486 at batcomputer.TN.CORNELL.EDU>, garry at batcomputer.TN.CORNELL.EDU (Garry Wiegand) writes:
>I've been subjected to an unpleasantly large number of operating systems
>over the years (is WYLBUR still out there somewhere?), and I'm a VMS
>partisan. What comes to mind quickly:
>
>1) Command names and switch names are reasonable, in English, and consistent
>   across all the different programs. I don't have to carry a stupid encoding
>   table around in my head.

Oh yes, and along with those verbose commands goes a command line which can't
be over 255 characters long, and a library-archiver, compiler, and linker
which can't take wild cards.  Real nice when you have a 100-module program.

Most Unix programs will print out a line or so of "usage" diagnostics if you
invoke them with bogus arguments.  Do VMS programs do this?

>
>2) The on-line Help is well-indexed, and it's HUGE. They've recently started
>   digesting the language references into Help entries; I rarely need
>   to page through a manual anymore.

Tell me, is there one for the Fortran under VMS 4.x?  On our 3.x VMS systems,
we did indeed have a detailed online help for Fortran, and we have such a
help now for C, but not for Fortran.  Did someone just forget to install it,
(system manager is baffled) or is it an "extra" (cost) item, or what?

Unix online help need not be "HUGE" because the system interface isn't "HUGE."
I think VMS is marvelous from many user points of view (despite my criticisms
herein) but the system interface is a monstrous headache because of the
complexity.

>
>3) The source-line debugger is exceedingly useful for program development and
>   (after several years of hard work at DEC) I can say it works well.

That's nice, BUT what do you do when the program dies in an alpha-test
environment?  You get a nice stack-dump printout, but do you get a "core"
which can be analyzed (especially if the sequence leading up the the crash
is not easily reproducible?).  (I _think_ there was supposed to be an option
to RUN which would cause a program to produce the VMS equivalent of a core
dump when it dies, but then can you pass parameters to the program, which
as best as I understand cannot be done with RUN?)

>
>4) The system services are logical, consistent, and well-documented. Anything
>   a utility can do, a user program can do too. (And if you want to tickle the
>   kernel, there *is* a thick manual on the system internals.)

Could you then do me a favor.  Show me how, in Fortran, I would go about
setting the protection (no fancy ACL stuff, just basic RWED protections)
on a file which I am creating.  (In C it's easy enough, since the protec-
tion is specified when the file is created, which of course is tied to the
straightforward Unix way of doing things!)  Please show actual code, such as
a USEROPEN program, together with the OPEN() statement that calls it, to run
on VMS 4.2.  Or even show me how I can do it in assembler.  (I hesitate to
say show me how to do it in the system programming language, since Bliss-32
is an "extra-cost" [and not really very commonly used outside of DEC, unlike
C which is commonly used outside of Unix systems, let alone AT&T machines]
option which I don't have.  I think the analogy fair since that is what I
would probably do if I needed to change the protection of a Unix file from
Fortran [I would call chmod() in a C routine].)

See also my comments under 2) about the system interface.  It is massive,
complex, and cumbersome, as well as introducing kludges into common pro-
gramming languages, to be blunt.  VMS does indeed pride itself on
accessibility of system routines from "any" language, but this occurs at
the cost of kludgey extensions (like Fortran STRUCTUREs and RECORDs and
%val()s and %loc()s) to common programming languages, that a user would
actually WANT to program in.  C, which is a fairly common, "ordinary"
programming language and sees wide use and portability even in non-Unix
environments, fits the UNIX system interface very naturally and needs no
such kludges to use it.  (It is commendable that DEC has seen fit to switch
rather than fight, and has provided an extensive UNIX-like interface to
the VMS system within C.)

>
>5) VMS, she doesn't die, she doesn't break, she doesn't lose files, she
>   just keeps running along. It's pretty trustworthy.

Oh yes, remember the security hole in VMS 4.1 about a nonprivileged user
being able to crash the system by entering certain line-editing sequences
in response to a prompt (involving ^B and some other escape codes).  I
succeeded in doing this once from DCL, and we have a plain VMS system, no
special private kernel drivers installed.  VMS 4.2 also kicked the bucket
on me the other week when I was trying to access the help library.  The
system just barfed, and the console dump contained my process name.  And
I wasn't even trying any funny business or having any special privileges.
Needless to say, Unix has never done this kind of thing.

It is indeed possible for Unix files to get trashed if they have been "writ-
ten" on (to the buffer cache) at a time which is less than the periodic system
buffer flush period (typically 10-20 seconds) before a physical failure.  It
is however possible under SysV (and maybe BSD, but I'm not sure) to
open() a file with an O_SYNC option, which will not return from the write()
until the data has physically gone onto the storage medium.  To do this is,
unsurprisingly, much less efficient, but that, as with VMS RMS, is the price
which is paid for security.  Any user also can tell the system to flush the
entire buffer cache with the sync() call, if they are worried about the
integrity of what they have just written.

>
>I like MacIntoshes too, but that operating system is still in its infancy -
>"Inside the Mac" is not recommended light reading.
>
>PS - I don't buy the argument about "portable systems"! This industry is much
>   too young to constrain itself to just one way of doing things. In the
>   graphics system I designed last winter, I stole good ideas wherever I
>   found them. From VMS, Unix, the Mac, even one from IBM! Not to mention
>   all the "graphics packages" that had gone before.
>
>   In diversity there is much richness.

If so, I am exceedingly glad that UNIX is part of that richness.

>
>
>--
>garry wiegand   (garry%cadif-oak at cu-arpa.cs.cornell.edu)
-- 
 -------------------------------    Disclaimer:  The views contained herein are
|       dan levy | yvel nad      |  my own and are not at all those of my em-
|         an engihacker @        |  ployer or the administrator of any computer
| at&t computer systems division |  upon which I may hack.
|        skokie, illinois        |
 --------------------------------   Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa,
						vax135}!ttrdc!levy


-- 
 -------------------------------    Disclaimer:  The views contained herein are
|       dan levy | yvel nad      |  my own and are not at all those of my em-
|         an engihacker @        |  ployer or the administrator of any computer
| at&t computer systems division |  upon which I may hack.
|        skokie, illinois        |
 --------------------------------   Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa,
						vax135}!ttrdc!levy