Using Procedure Generators INQUIRY, PROCGEN and PROCFORM
From "VS Procedure",  Access 87, March 1987
[ Prior Article ]     [ Return to the Catalog of articles ]     [ Next Article ]

This month we'll cover some of the ways you can create procedure files, including the use of procedure generators and some manual techniques you can use to augment them. While this column is generally aimed at experienced programmers, the use of procedure generators should also be of interest to system administrators and as examples for those just beginning to tackle the fundamentals of Procedure.

How does one begin to write a procedure? A few people sit down at the keyboard and begin typing (I'm generally one of them). Most use scraps of other procedures, a skeleton procedure, or a procedure generator. Each approach has it's advantages:

• Using old code: Easily the most popular approach. Copying previously-written code is a good way to ensure consistency of style, though occasionally at the cost of some creativity. Tested code in a familiar style is also easier to understand and modify to the new task - though don't let that familiarity blind you to necessary differences between the new and old tasks!

• Skeleton procedures: a properly constructed skeleton ("boilerplate") procedures can be of great use, but few of us have the time to create them in a manner that allows their use in a variety of situations.

• Procedure generators: several utilities on the VS generate procedure files as output. While the code produced from these programs is seldom perfect, it is often a good starting point for further editing.

Procedure generators available

To my knowledge, only three procedure generators exist on the VS. They are:

1. INQUIRY: regular users of this Wang utility may have noted a SAVE option when exiting. The INQUIRY utility can create a procedure that duplicates the query just completed. This procedure may be used directly, or become the nucleus of a new procedure. Definitely the easiest to use and most reliable of the procedure generators.

2. PROCGEN: this USERAID automates a selected group of Wang utilities, producing a procedure that sometimes even works. Produces standard, if ugly code. Dead wrong entries for some utilities (e.g. REPORT).

3. PROCFORM: another USERAID, and one better suited to changing system software. Interprets the programs run within it directly during run-time, creating procedure code to duplicate the process exactly. More difficult to use than PROCGEN.

The SAVE option in INQUIRY

At the end of the INQUIRY utility, the user is presented with options for further processing (the End of Query screen mentioned in Wang's File Management Utilities Reference). Pressing PF2 at this screen will allow you to save the query just run as a procedure. This procedure exactly mirrors the parameters you entered to run the last query, including INPUT, CONTROL and QUERY data. This procedure can be run directly to duplicate the effect of running INQUIRY manually.

After selecting the Save option, the user is prompted for the location of the completed procedure. While this can be any library on any volume, is is recommended that saved queries be stored in an identifiable library, such as 'xxxINQ', where 'xxx' is the user's initials. After entering this information, the user is prompted to specify two processing options:

1. DISPLAY: this selects whether the query will be displayed before executing. If YES, the query will be displayed for used review and modification; otherwise, no change is possible. The default is YES.

2. END RUN: this options selects the action to be taken after the query has been processed. If NO, the End of Query screen will be displayed for further use of the INQUIRY utility; if YES, INQUIRY will terminate immediately. The default is NO.

While it is seldom necessary to create procedures based entirely on the INQUIRY utility, it is helpful to know that this option can be used to produce a reliable procedure.

Using PROCGEN

PROCGEN is easy to use. Merely run it, specify the location for the generated procedure, and select the utilities to be included. Options include COPY, SCRATCH, SORT, TRANSL, CONVERTC, DISPLAY, DISKINIT, DATENTRY, REPORT, INQUIRY, BACKUP, and other items. You may also specify a RUN or SET statement.

After selecting the program to be run, PROCGEN prompts you for the data to be passed to the respective keywords for each GETPARM screen. Since many utilities have capabilities that were added in the last few years, this list of keywords is not complete. Consider the SHARED options for file opening the DISPLAY and SORT utilities, for example; since these items have been added to the utilities fairly recently, PROCGEN does not recognize them and they must be added manually.

The principle problem with PROCGEN is that it is based on old forms of the Wang utilities. A related problem in that it does not come up with correct names for some GETPARM screens.

When using PROCGEN, you must always keep in mind that every keyword will be filled - regardless of whether you wanted the default values overridden. For example, the DATE parameter on the OPTIONS screen of REPORT will be filled with the run date at the time the procedure was generated, rather than accepting the default: today's date. This means the date of the procedure's inception will be carved onto all of your reports forever unless you remove the parameter from the procedure! Always review the finished procedure in the Editor before putting it to use.

Naturally, PROCGEN will be of little help in writing procedure code for items it does not recognize. In these cases, you are busted back to manual coding, testing, and editing.

PROCFORM: direct object interpretation

PROCFORM offers a more sophisticated approach. Rather than retaining a large amount of dated knowledge about utilities, PROCFORM interprets the GETPARM screens themselves during run time, identifies the keywords and the data entered, then creates a procedure to duplicate the process.

When using PROCFORM, the user specifies the file location for the final procedure and the starting step label number. (Yes, all steps and sub-steps are numbered.) You must then choose the program to be proceduralized, enter a statement manually, show the generated source to date, or enter the Editor. A limited amount of review and modification are available.

During the run, GETPARMs will appear when information is needed by the system. As each GETPARM screen appears, you must enter the field information as you wish it to be and then print the screen from the Command Processer (this assumes you have access to the HELP key). PROCFORM intercepts this screen dump file and uses it to determine the field names and the data you have entered.

In other words, you run the process manually once and create a procedure from the entries you make to each GETPARM. At the conclusion of each step, you are presented with the results so far and can further edit the procedure. Simple, huh?

Well, it's not that simple. First of all, it's typical to write procedures for processes that you cannot run at this time. Only a fool would use production data libraries to test a purge procedure, for example. Thus, in many instances you must knowingly mislead PROCFORM, specifying near-truths and hoping to correct them before the procedure enters production.

The second fallacy is that you will faithfully remember to print each screen at the proper moment and with correct data entered. You can count on a stressful run while using PROCFORM, always sweating every item, always aware that your no-brainers will be faithfully reproduced in the final procedure. To minimize some of this stress, I use a Multi-Station Glossary to mimic the keystrokes necessary to print a screen; thus, I need only press one button to accomplish the task. Naturally, I always use PROCFORM on well-defined tasks with straightforward solutions - never on the convoluted, wrenching problems.

In spite of the drawbacks, PROCFORM is generally my choice among procedure generators. I often use it for the notorious "one-shot" jobs that occur in any programmer's life - the kind that often require several revisions before they're right. Using PROCFORM allows me to tackle this type of problem by making minor revisions to a procedure, rather than by tediously retyping data and hoping against keyboard errors; it also documents my efforts for future reference (or blame).

Conclusion: are generators worth the effort?

Where do procedure generators fit? The three mentioned above can be used with varying success by journey-level procedure writers to produce workable results with less effort. I suspect that the productivity differences will be felt most in larger procedures - those of 500 lines or more. Generally, most programmers would prefer to work with familiar code (e.g. their own), since this best reflects their personal taste.

If used consistently, procedure generators can help reduce some of the uninteresting elements of procedure writing and allow concentration on the primary task. To that end, they're of benefit.

Credits

Much of the information on PROCGEN in this article came from Patrick McMonagle's excellent Procedure Language manual, which accompanies his classroom instruction. My thanks to Pat for inadvertently assisting me. Other information came from the Procedure Language Reference, publication 800-1205-05, and by the File Management Utilities Reference, publication 800-1308-01. The latter two manuals have been updated through addendums distributed by Wang for the cost of shipping; these addendums are publications 800-1205-05.01 and 800-1308-01.01, respectively. The Procedure Language Reference Addendum is particularly recommended, as it contains many, many revisions to the language.

As always, I'm interested in the creative solutions you come up with using Procedure language. Please send any listings to me at the address below.

Next month we'll explore skeleton procedures and a procedure "generator" that assembles boilerplate paragraphs into semi-complete procedures.