Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!mcnc!ncsu!uvacs!edison!steinmetz!davidsen From: davidsen@steinmetz.UUCP (Davidsen) Newsgroups: net.decus,net.unix,net.usenix Subject: Re: Favorite operating systems query (UNIX vs VMS flaming!!!) Message-ID: <859@kbsvax.steinmetz.UUCP> Date: Mon, 4-Aug-86 15:23:02 EDT Article-I.D.: kbsvax.859 Posted: Mon Aug 4 15:23:02 1986 Date-Received: Thu, 7-Aug-86 03:17:48 EDT References: <486@batcomputer.TN.CORNELL.EDU> <1000@ttrdc.UUCP> <873@rti-sel.UUCP> <1320@psivax.UUCP> <909@rti-sel.UUCP> Reply-To: davidsen@kbsvax.UUCP (Davidsen) Organization: GE CRD, Schenectady, NY Lines: 107 Xref: watmath net.decus:440 net.unix:8820 net.usenix:673 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@rti-sel.UUCP> rcb@rti-sel.UUCP (Random) writes: >In article <1320@psivax.UUCP> friesen@psivax.UUCP (Stanley Friesen) writes: >>In article <873@rti-sel.UUCP> rcb@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@ge-crd.ARPA) "Stupidity, like virtue, is its own reward"