Item Subject: UDC Help GySgt Michael J. Riley wrote: > I would like to create a UDC that prompts me for a search string then > goes off and searches all the files in certain groups for a match. > Below is the UDC I tried. I'm very new at this HP stuff... > your help will be very much appreciated. No problem. And welcome to the 3000! :) > ------------------ > UDC > ------------------ > search > input searchstr;prompt="Enter search string " > mpex.pub.vesoft > print @.forms.myacct;search=caseless "searchstr";num > print @.job.myacct;search=caseless "searchstr";num > print @.prod.myacct;search=caseless "searchstr";num > print @.pub.myacct;search=caseless "searchstr";num > print @.source.myacct;search=caseless "searchstr";num > **** Several notes: 1. Consider using command files instead of UDC's. You'll find they are MUCH easier to maintain. The primary differences are: a. A UDC file may contain several commands, whereas a command file contains exactly one command. b. A given UDC command begins with the command name and ends with *'s. A command file does NOT begin with the command name (the name of the file itself is the command name), and it ends with no special delimiter (i.e., no *'s at the end). The biggest thing, though, is that a UDC is "registered" with the :SETCATALOG command, and can even be set system-wide (given enough capability). A command file is NOT registered in any special way. Similarly, if you want to change a UDC, you may have to keep the file under a different name. (Even if you "unregister" the original UDC file, other users may still be pointing to it.) Changing a command file, on the other hand, generally does not run into this problem. 2. Both UDC's and command files can accept parameters on the command line. It's probably much easier to say, for example :search abc instead of :search Enter search string: abc With a UDC, name the parameter on the "command" line. Give it a default value, if you like: search value="abc" With a command file, since there is no "command" line, there is a PARM statement: PARM value="abc" 3. As Michael Hensley pointed out, commands within UDC's and command files must be MPE commands. That is, you cannot provide a response to any program from within the command file. Fortunately, there are some ways around this. With MPEX, you can provide an INFO string that says "do this, then exit." For example, you can say run mpex.pub.vesoft; info="print @.forms.myacct; search=cl 'abc'; num" You can repeat this but use the other 'print' statements, if you wish. Or, you can use an indirect file, as also suggested by Michael. As others have pointed out, you can "pre-send" your responses to a flat file, then run the program using this file as input. For example, echo print @.forms.myacct; search=cl '!string'; num > cmds echo print @.job.myacct; search=cl '!string'; num >> cmds echo exit >> cmds run mpex.pub.vesoft < cmds (See #4 below for an explanation of '!string'.) You'd probably have to play some games with this, though, because MPEX will (by default) prompt you when the screen is full. Here, it would take the response from the 'cmds' file, which would 'eat' the next print command. (I think 'print' has an option where you can override this behaviour.) 4. Whether using a UDC parm or an MPE variable, there are times in which they must be 'dereferenced.' If it looks ambiguous to you (how can it tell if I'm looking for the string "searchstr" or the value of the variable "searchstr"?), then it's likely you need to dereference the variable. (This is *always* true with UDC parms.) In this case, that means using ...; search=cl '!searchstr'... So your final command file (say, SEARCH.PUB) may look something like: PARM string run mpex.pub.vesoft; info=& "print @.forms.myacct; search=cl '!string'; num" run mpex.pub.vesoft; info=& "print @.job.myacct; search=cl '!string'; num" (etc.) Of course, using the indirect file would make this even smaller and faster. As you may expect, this is a common task. <plug> While I have not used it myself, I have heard very good things about a tool called "Magnet", which I believe was written originally by Allegro Consultants. It used to be sold through SRN (Software Research Northwest). I think it's now part of one of the "toolboxes" from Lund. I'm sure someone would be happy to provide further details. MPEX works well, and is pretty quick, but it seems to suck up a fair amount of the machine. I've heard that Magnet is twice as fast (which boggles the mind). I have no idea what the system impact is from using it. </plug> --Glenn Cole Software al dente, Inc. [log in to unmask]