🚀 go-pugleaf

>>>
>>>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)!

	This is getting absurdly nested, but as the old saying (almost)
        goes, "the context must be kept" (I know, it really doesn't,
        but then, we all make up old sayings every day, right).
        
        VMS has a simple command language specifically for describing
        command lines.  You describe the command verb, the image
        name or routine name which implements it, the number and
        data type of parameters, qualifiers, and qualifier values.
        
        This description is a separate module of a program.  For
        "real" commands, it's generally compiled directly into the
        master system command table image (SYS$SHARE:DCLTABLES.EXE),
        where DCL will look by default for commands.
        
        However, you can also compile that description file, using
        the SET COMMAND/OBJECT command, into a standard .OBJ file,
        which can be linked in with the program.  You then get the
        command line you wish to parse (you can get it from DCL by
        LIB$GET_FOREIGN, or by whatever other means you wish), and
        call the CLI$DCL_PARSE service to parse it according to the
        command description linked into the program.
        
        The program uses simple services like CLI$PRESENT to ask
        if a qualifier or parameter was specified, or CLI$GET_VALUE
        to get the value.  Each parameter and qualifier has a name
        by which it's known to the program (like a standard variable
        name), passed as a string to the CLI$ routine.  This means
        that the command description can be radically modified (for
        example, translated), and the program itself doesn't have
        to be modified at all.
        
        Because DCL has an exact description of the syntax of the
        command, it can issue reasonable diagnostic messages (although
        in many cases it *could* do better than it *does*).
        
        For example...
        
        	Verb Foobar
        		Image FOOBAR
        		Parameter P1, Label=F1, Prompt="Which Foo",
        			Value (Required, Type=$INFILE)
        		Qualifier Bar, Label=F2, Value (List)
        
        describes a command FOOBAR which is implemented by the program
        FOOBAR (on SYS$SYSTEM, by default), with an input file parameter
        P1 (known to the program by the label "F1" and to the user
        by the prompt "Which Foo"), which the user is required to
        specify; and an optional qualifier BAR (/BAR in user syntax),
        which the program refers to as F2.  /BAR can take a list
        of values, of ordinary string type.  E.g.:
        
        	FOOBAR/BAR=(A,B,C,HIPPOPOTOMUS) SOME-FILE.FILE-TYPE
        
        You can specify things like whether a qualifier affects only
        the particular parameter it follows, or the entire command;
        whether certain parameter and/or qualifier combinations are
        mutually exclusive ("DISALLOW" statements), define keywords
        which can be used as parameters (and DCL will resolve
        abbreviations and report ambiguities), and so forth.  There's
        quite a lot of power and flexibility in the language.
        
        And yes, as I said (but to make it explicit), any Joe Blow
        program can use every bit of the capability of this interface
        with a very small amount of programming.  Even non-privileged
        users (it takes privilege to put a command in DCLTABLES.EXE,
        obviously, since that's a shared resource) can use it...
        either by linking the command description .OBJ file into
        the image and using the program as a "foreign command" (defining
        a DCL symbol to "$image-name"), or by doing a SET COMMAND
        to compile the description and insert it in the user's memory
        image of DCLTABLES... which makes it just like a "real" command
        within the user's process.
        
	/dave

Dave Butenhof
ZKO2-3/K06
Digital Equipment Corp.
110 Spitbrook Road
Nashua NH 03062

clt::butenhof
butenhof%clt.DEC@decwrl.ARPA
{allegra,shasta,decvax}!decwrl!dec-rhea!dec-clt!butenhof

Any resemblance  between  the  opinions  expressed  in  this article and any
actual  opinions,  living  or  dead,  is strictly coincidental and in no way
binding  upon either myself or upon Digital Equipment Corporation, much less
upon reality itself.

``Any sufficiently  advanced  technology  is indistinguishable from a rigged
demo.''