From:	MERC::"uunet!CRVAX.SRI.COM!RELAY-INFO-VAX" 24-JUN-1992 02:42:48.84
To:	info-vax@kl.sri.com
CC:	
Subj:	Re: User-Defined Verbs


In article <01GLFNBW265S000LHQ@EKU.BITNET>, STUKING@EKU.BITNET ("Steven C. King ", Ryu) writes:
|> Hello,
|> 
|>       Is there anyway to create a verb with the DCL command SET COMMAND, and
|> the verbs could be copied in a subprocess? 

This kind of topic has popped up several times recently, so at the
risk of harsh criticism, I'll offer our experiences in this area.
We have gobs (that's an esoteric mathematical value slightly less
that zillions) of utilities and tools that we wrote that are part
of our software development process for VMS.  Lots of our work is
distributed using subprocesses, etc. and for quite a while we
agonized over how to handle DCL table updates so the subprocesses
would get them correctly, etc.

In the end, we opted to mangle the tools slightly with a front-end
routine in each one that read a foreign symbol command line and
passed it on to CLI$DCL_PARSE.  The tools each had their command
table compiled in via SET COMMAND/OBJECT.  Once the tools ate the
command line, and passed the string on to CLI$DCL_PARSE, the rest
of the tool operated unchanged, i.e. was able to query the currently
parsed qualifiers and parameters with no change.

We added the routine to the link line, and made the first action of 
the routine look like (VAX C):

        long grammar();
        long sts;

        if( $VMS_STATUS_SUCCESS( sts = sas$dcl_parse( grammar )))
                sys$exit( sts );

The sas$dcl_parse routine grabs the command line, handles the parse,
arranges for error reporting, and returns the status code.  Note
that the status code has been modified to add the "suppress output"
bit so the return to VMS won't signal the message a second time...

Needless to say, we then changed our tools to be invoked by DCL
foreign symbol mechanisms instead of as DCL CLI verbs.  The symbol
definitions were always inherited by subprocesses, picked up by
network tasks, etc.  We also didn't have to edit our DCLTABLES
periodically, or worry about updating distributed cluster-wide
tables, or recovering from VMS installs, etc. etc. etc.

Just a thought, but it has certainly made our lives easier...

-- 
Tom Cole, SAS Institute Inc. VMS R&D  cole@nepenthe.unx.sas.com

