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

[Davidsen]

I apologise for the length of this, I cut it as much as posible.
Readers have to see the pro-UNIX posting (mildly sarcastic) and the
pro-VMS reply (rude and personal) to appreciate my answer about the
technical shortcomings of the answer.

In article <909 at rti-sel.UUCP> rcb at rti-sel.UUCP (Random) writes:
>In article <1320 at psivax.UUCP> friesen at psivax.UUCP (Stanley Friesen) writes:
>>In article <873 at rti-sel.UUCP> rcb at rti-sel.UUCP (Random) writes:
>>>
	the original pro-VMS statement

>>>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.
>>
	the somewhat sarcastic reply

>>	Oh, *great*:-) How does the DCL parse the arguments for a user
>>written application program?? I can't see how it can do this without
>>some rather messy interface requirements.  This really sounds like a
>>way to make user-written programs second class citizens on the system.
>>I think the individual program is better qualified to analyse its own
>>arguments, whay is really needed is a *standard* for this, like getopts(3)!
>>-- 
>>				Sarima (Stanley Friesen)
>
	the vituperative personal attack

>Have you ever possibly considered finding out about something before
>talking about. It will usually make you look a lot less like a fool.

	followed by a correct but incomplete technical rebuttal!

>The DCL command definitions simply define how many parameters can be used,
>which ones are optional, the possible switches, The possible switch locations,
>and the possible types for parameters and switches. It can also be used
>to change the default values based on interactive or batch operation.
>The possible types are simply string, number, file, acl, etc. and also
>one of a list of user defined keywords. DCL is capable of parsing these
>properly because you give it a definition that defines all these possibilities.
... another 30 lines or so of "simple" explanation deleted ...

No one in their right mind could consider this "simple".

>
>An example of the definition file follows so that you might know what you
>are maligning.
... 13 lines of more "simple" stuff deleted ... loaded with keywords ...
>Simple, clean and easy to use. Definable on a per user basis, defined for
>a group of users by the system manager or on a system wide basis. The program
			  ^^^^^^^^^^^^ That's convenient.

>interface is also clean. To get the values, you only have to issue the 
>following call.
>
>	call dcl$get_value ("input_area", string_variable)
>
>and you have it. Easy, no? So, next time, ask someone about a feature you
		  ^^^^^^^^^ in a word **NO**. To write a program asking
about the calling sequence instead of typing the command at the prompt
is not by any stretch of definition "easy".

>know nothing about before you go shooting off your mouth (or keyboard).
^^ more tact and courtesy ^^

What really made this answer so obnoxious is that after all this
overkill flame, the poster didn't say (or, could it be, didn't know)
that the user can define his/her commands with a mechanism similar to
an alias, and get no parameter checking at all. It can even be put in a
startup file and done at login.

Examples: (! starts comments)
  $ check:==$usr$disk:[user.bin]check.exe ! binary executable image
  $ redo:==@usr$disk:[user.bin]redo.com   ! DCL (shell) command file
     ^   ^ ^   ^       ^    ^    ^
     |   | |   |       |    |    |__ filename
     |   | |   |       |    |_______ subdirectory
     |   | |   |       |____________ user directory
     |   | |   |____________________ device (may be logical = directory)
     |   | |________________________ $ for binary, @ for DCL shell
     |   |__________________________ mystic assignment operator
     |______________________________ symbol now defined as valid command

I hope this has spread some rational light on the subject. The ability
to have the arguments parsed is very useful, but time consuming for the
system operator. The method described above provides no checking, but
is easily doable by the user. It is far easier to write commands
knowing that they will never get bad arguments than to put recovery
code in each and every program. VMS provides both.

Please don't count me as pro-VMS, I have used it since we got our first
VAX (I believe it was S/N < 30) and still only consider it acceptable.
I find the UNIX interface more convenient and the response far better
for small programs due to the overhead of process start in VMS.
Flamers, please MEASURE the overhead for UNIX and VMS on similar
machines (in cpu or disk access) before rebutting this.
-- 
	-bill davidsen

  ihnp4!seismo!rochester!steinmetz!--\
                                       \
                    unirot ------------->---> crdos1!davidsen
                          chinet ------/
         sixhub ---------------------/        (davidsen at ge-crd.ARPA)

"Stupidity, like virtue, is its own reward"