Add Powerful Generic Processing to Your Applications

November 9, 2011 Ted Holt

Each month I perform a ritual by which I attempt to placate the gods Sarbanes and Oxley. One task involves repeatedly selecting a certain menu option, filling the entry fields with different values each time. What an annoyance. Fortunately there are ways to eliminate repetition programmatically, and the use of generic names is one such way.

A generic name is one that ends with the asterisk wild-card. Many CL commands accept generic parameters. I have written about this before.

But when you want to run a certain command over a group of objects, and the command does not allow a generic object name, you’re not out of luck. You just have to do a little work. Here’s an example. This first bit of code contains the source code of a command that accepts a generic file name in a qualified object parameter.

            CMD        PROMPT('Do Something Generically')

            PARM       KWD(FILE) TYPE(QUALFILE) MIN(1) MAX(1) +
                         PROMPT('File')      

QUALFILE:   QUAL       TYPE(*GENERIC) DFT(*ALL) SPCVAL((*ALL)) +
                         EXPR(*YES)
            QUAL       TYPE(*NAME) MIN(1) EXPR(*YES) +
                         PROMPT('Library')

I’ve defined a generic name in the first QUAL statement. You may also define generic names in PARM and ELEM statements.

Defining a generic name does one thing: it tells the CL command processor to allow a generic name in an input entry blank. Defining a generic name does not create a list, as globbing does in Qshell and other shells of the Unix flavor. You have to create the list yourself.

If the generic name refers to objects, creating the list of objects is easy. I use the Display Object Description (DSPOBJD) command to build a list of files in an outfile, as show below:

pgm  parm(&inFile)

   dcl   &inFile     *char    20
   dcl   &FileName   *char    10
   dcl   &LibName    *char    10

   dclf  qadspobj  opnid(fd)

   chgvar   &FileName    %sst(&inFile  1 10)
   chgvar   &LibName     %sst(&inFile 11 10)

   dspobjd  obj(&LibName/&FileName) objtype(*file) +
              output(*outfile) outfile(qtemp/objd)

   ovrdbf   qadspobj   tofile(qtemp/objd)
   dowhile  '1'
      rcvf    opnid(fd)
      monmsg  cpf0864  exec(leave)
      /* do something with fd_odobnm */
   enddo

   dltovr     qadspobj

This command-processing program generates a list of objects.

I could also use the List Objects (QUSLOBJ) API. The API would execute faster, but I’ve never gotten around to developing that solution.

Notice the comment inside the DOWHILE loop. This is where you reference the object name that was just retrieved from the outfile in QTEMP. What you do here is limited only by your imagination.

As I just said, you might run a command that does not allow a generic parameter. If it’s a command that you cannot modify, such as one of IBM‘s commands, you have a way to run that command generically. And if the command is one to which you do have source code, you may find it easier to create this new command and CL program than to add generic processing to the executed command.

Or you might call a program, possibly using the information from the outfile to build a necessary override. Or you could run a Qshell script. What you do here depends on your application.

In my programming, I have only used generic parameters with object names, but nothing stops you and me from using them with other types of data. For instance, you could define a generic vendor number or a generic customer name. In such a case, you would probably define the parameter to be of character data type, rather than generic. It would be up to you, of course, to write the code to turn the generic value into a list.