croll@oblio.dec.com (07/10/86)
> 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) VMS provides two mechanisms to help parse commands for user-written applications: the command defintion utility, and the CLI interface routines. The command defintion utility allows you to define your own DCL commands, and to place them in the DCL tables, either system-wide, or for your own process, or link them into your application image. System-wide means you modify the DCLTABLES.EXE sharable image, and the modified image gets loaded each time you create a process; "for your own process" means you can modify at any time the copy of DCLTABLES that was loaded when your process was created. You first create a file that defines the command (with appropriate parameters, qualifiers, etc.), and then use the SET COMMAND DCL command to add your command to the tables. If you don't want to modify DCLTABLES, you can link the command tables with your image. If you want your image to be able to acquire and parse many commands, one after the other, then you have to link the command definitions with your image; if you only deal with one command each time your image is invoked, then you can modify DCLTABLES. This mechanism requires that your commands be of the form: <verb> <qualifier(s)> <parameter(s)> <qualifier(s)> The only required part is the <verb>, you can have as many parameters or qualifiers as you like, and you can make the qualifiers positional if you like (that is, you can require that a qualifier qualify only the verb, or only the parameters, or both). Qualifiers are indicated by a "/" character. Qualifiers can also have a value or a string associated with them. You're limited to 256 characters on one line, although you can continue a command across up to four lines, for a maximum limit of 1024 characters. The continuation character is a hyphen. For example: BACKUP /IGNORE=INTERLOCK FRED.BCK/SAVE_SET [MERTZ]/NEW_VERSION BACKUP is the verb; /IGNORE is a qualifier on the verb; FRED.BCK is the first parameter; /SAVE_SET is a qualifier on that parameter; [MERTZ] is the second parameter; and /NEW_VERSION qualifies the second parameter. Note that DCL will complain if you put the /IGNORE at the end of the command line, since it will think that it is qualifying the second parameter, when it's supposed to qualify the verb. All this stuff is parsed and checked by DCL before BACKUP is invoked, and it's all defined by entries in DCLTABLES. You can define commands in a similar fashion for your own application. (Of course, if your application language doesn't fit the <verb> <parameter> model, you can't use this stuff, and you'll have to invent your own parser.) Once your image is started, it can use the second mechanism to get the information from the command line (and even acquire and parse subsequent command lines). This mechanism involves four run-time library subroutines (otherwise known as the CLI interface routines), called by your application. One determines the presence of a token in the command string, and one returns the value of a qualifier or parameter. These two are used when your program is invoked by a DCL command. If your program is prompting for commands on its own, two more subroutines are provided: one to give the command line to DCL to parse it, and one to invoke the action routine associated with the most recenly parsed verb. This is a brief description of the mechanisms VMS provides to allow user applications to parse commands. All VMS utilities (COPY, BACKUP, DIRECTORY, etc.) use these mechanisms to at least parse the command line that starts them. For more information about them, look in the VMS documentation. The command definition utility is documented in volume 7B, and the CLI routines are documented in volume 8A of the VMS V4.4 doc set. John Croll ...decvax!decwrl!dec-rhea!dec-oblio!croll