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

[Random]

I promised myself that I was going to stay out of this annual OS debate.
However, I weakened. So here it comes.

In article <1000 at ttrdc.UUCP> levy at ttrdc.UUCP writes:
>In article <486 at batcomputer.TN.CORNELL.EDU>, garry at batcomputer.TN.CORNELL.EDU (Garry Wiegand) writes:
>>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.
>

The librarian and most compilers WILL take wildcards and have done so for
some time. True the linker won't which is a bother. However, it would be nice
if you check your arguments before posting them.

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

No. VMS programs will not let you invoke them with bogus arguments. Since
the arguments are parsed by DCL before the program is invoked, if you give
too many parameters or an unknown switch DCL will reject it with an error
message that points out the specific problem.

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

This is the fault of your system manager for not reading the installation
document that came with the fortran compiler. There are really 2 distributions
on the tape. One for fortran and one for the help and the help is even more
extensive than the one on 3.x.

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

VMS online help is HUGE because it is complete. Unix help on the other hand...

>>
>>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?)
>
A program can be linked to cause a "core" dump. Also, the core dump is 
analysed by the symbolic debugger.

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

Since I don't write in fortran, I can't give you the exact details, but
the useropen routine should allocate a protection XAB and link it to the FAB
passed into the useropen routine. When the open occurs, the protection
will be right.

>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.)
>
Fortran structures, records, etc. do not exist for the purpose of kludgey
interfaces to system routines. They exist to enhance fortran's capabilities.
Structures and records provide better programming practices and %val and
%loc allow rather sophisticated pointer operations to be done.
>>
>>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.
>
Would you mind also including the list of unix kernal bugs that can be activated
by any user to kill the system. Assuming that there is disk space to keep the
list. The above bug makes a good example for you to point to because it
stands out. The reason it stands out is because it is the ONLY bug of it's kind
I have ever seen since about version 2.5

>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.
>
Please let us not forget the great fun of trying to overwrite a file when
the file system is full. The write fails as would be expected but has the
nasty side effect of leaving a zero length file. Goodby data.
>>
>>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

Before you get the idea that I am a rabid UNIX hater, I actually like some
features of unix. I prefer VMS for it's consistancy, reliability and
versatility. There are many unix emulators on VMS because it has the power
and flexability to do a lot of different things easily. I have never seen
a VMS emulator on unix however. And as for the good things about unix,
I have ported or duplicated them on VMS so that I now have the best of both
worlds.
-- 
					Random (Randy Buckland)
					Research Triangle Institute
					...!mcnc!rti-sel!rcb