[net.usenix] UNIX vs VMS

mouse@mcgill-vision.UUCP (der Mouse) (06/26/86)

[Bug food.  No, who wants to feed a bug?!  Bug killer, I guess.]

     Some history.  I started on VMS and switched to UNIX as soon  as we
got it.   So  my  view is not generated by lack of  knowledge  of either
system.  In fact I am the local wizard for both of  them (and lemme tell
you it's not always a pleasant thing to be!).

>> [...] I'm a VMS partisan. What comes to mind quickly:
>> 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?).

     The really good debugger is the only thing I miss at all often from
when I used VMS.  In fact it's very close to the  only thing I miss from
VMS at all.

>> 4) The system services are logical, consistent, and well-documented.
>> Anything a utility can do, a user program can do too.

     Let's  see a user program  implement  DCL.   Or DEBUG.  Okay, those
really aren't fair, are  they?  (But under  UNIX, on the other hand...).
Or any  of  the  DCL  builtins, like  ASSIGN,  DEFINE,  ATTACH, DEPOSIT,
EXAMINE, ...

     I want  to  see where the documentation  exists to  tell me  how to
perform the functions of the following commands from a user program; let
us be kind to you and postulate I am writing in assembly:
	- DISMOUNT (where is sys$library:dismntshr mentioned?)
	- INITIALIZE
	- UNLOCK
and  probably  others I can't  find in  10 minutes.  I  don't want to be
referred to the internals manual; see the next comment.

>> (And if you want to tickle the kernel, there *is* a thick manual on
>> the system internals.)

     Which costs what  was it,  a thousand  dollars?  To  a  university?
Sorry.  UNIX kernel *source* (not just documentation that only tells you
how, source that shows you how and that you can fix bugs  in) comes with
it.

>> [the above item 4]
> 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.

     I second this challenge, IN FORTRAN.

> Or even show me how I can do it in assembler.

     RTFM, I'm sorry  to say.   I am writing this from the RMS reference
manual, I do not remember all this stuff!

fab:	$fab	xab = xab 	;anything else you want here, like file
				;attributes or record attributes
xab:	$xabpro pro=<rwe,rwed,re,e> ;can also be set at runtime, see
				;the manual
	....maybe set filename in fab or something....
	$create	fab=fab		;if creating on the spot, do just this
	$open	fab=fab		;otherwise, open, change the xab, and
	movw	something,<xab+xab$w_pro> ;close again
	$close	fab=fab

This  could  be worked into  a  useropen  procedure  easily if I had the
FORTRAN manual handy, though the useropen procedure would be in MACRO.

> VMS does indeed pride itself on accessibility of system routines from
> "any" language,

and then  neglects  to mention that  (for  example)  to access  the  RMS
service $create from a high-level  language you create  a FAB  structure
(field  order and some  contents  not documented) and  call sys$create()
with  this  structure.    I  learned  this  through   a  combination  of
intelligent guessing and reading other people's code.

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

     I can write you a real trustworthy system.

	spl7();
	while (1); /* note semicolon */

My point,  of course, is that functionality  must be considered as well.
By the way, VMS  *does* break on occaison, and when it does, you haven't
a ghost of a chance of figuring out why.  On UNIX, on the other hand....

>> I like MacIntoshes too, but that operating system is still in its
>> infancy - "Inside the Mac" is not recommended light reading.

     Neither is the VMS internals manual....

>> 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 diversity there is much richness.

     Like constraining yourself to running on a VAX?  Riiight.
-- 
					der Mouse

USA: {ihnp4,decvax,akgua,utzoo,etc}!utcsri!mcgill-vision!mouse
     philabs!micomvax!musocs!mcgill-vision!mouse
Europe: mcvax!decvax!utcsri!mcgill-vision!mouse
        mcvax!seismo!cmcl2!philabs!micomvax!musocs!mcgill-vision!mouse
ARPAnet: utcsri!mcgill-vision!mouse@uw-beaver.arpa

"Come with me a few minutes, mortal, and we shall talk."