UNIX vs VMS
der Mouse
mouse at mcgill-vision.UUCP
Thu Jun 26 16:45:15 AEST 1986
[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 at uw-beaver.arpa
"Come with me a few minutes, mortal, and we shall talk."
More information about the Comp.unix
mailing list