Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!philabs!mcnc!rti-sel!rcb
From: rcb@rti-sel.UUCP (Random)
Newsgroups: net.decus,net.unix,net.usenix
Subject: Re: Favorite operating systems query (UNIX vs VMS flaming!!!)
Message-ID: <909@rti-sel.UUCP>
Date: Thu, 10-Jul-86 10:02:09 EDT
Article-I.D.: rti-sel.909
Posted: Thu Jul 10 10:02:09 1986
Date-Received: Fri, 11-Jul-86 22:07:09 EDT
References: <486@batcomputer.TN.CORNELL.EDU> <1000@ttrdc.UUCP> <873@rti-sel.UUCP> <1320@psivax.UUCP>
Reply-To: rcb@rti-sel.UUCP (Random)
Organization: Research Triangle Institute, NC
Lines: 68
Xref: linus net.decus:405 net.unix:7846 net.usenix:598

In article <1320@psivax.UUCP> friesen@psivax.UUCP (Stanley Friesen) writes:
>In article <873@rti-sel.UUCP> rcb@rti-sel.UUCP (Random) writes:
>>
>>>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.
>
>	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)

Have you ever possibly considered finding out about something before
talking about. It will usually make you look a lot less like a fool.
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.
Also, one of the possibilities is type=rest_of_line which will turn off all
parsing and make the rest of the line be one parameter. The advantages it
gives you are that if you give it too many parameter, it give you an error
message. If you give it too few, it will prompt for what it needs. If a 
switch requires a value and you don't give it one, it will issue an error.
If a switch does not take a value and you giv it one, it will issue an error.
If you give a string to a parameter of type number you get an error message.
And if you use a switch that is not defined, you get an error. Beyond type
checking, it does not try to interpret your parameters and switch values.

An example of the definition file follows so that you might know what you
are maligning.


! The TeX command

define verb tex
	image tex_base:[programs]tex
	parameter p1, label=input_file
	parameter p2, label=second_file
	qualifier font_directory, label=font_area, nonnegatable, value(list)
	qualifier input_directory, label=input_area, nonnegatable, value(list)
	qualifier batch, batch


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
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
know nothing about before you go shooting off your mouth (or keyboard).
-- 
					Random (Randy Buckland)
					Research Triangle Institute
					...!mcnc!rti-sel!rcb