No More Tears A painless approach to GETPARM and PUTPARM programming
From "VS Workshop",  Access to Wang, September 1991
[ Prior Article ]     [ Return to the Catalog of articles ]     [ Next Article ]

Last month I described the DL file management utility distributed by the United States Society of Wang Users (USSWU) as a part of their VSAIDS collection. DL makes a great print file manager, since it shows the contents of the first record in the file and makes it easy to view, print, and delete files.

I decided to try to extend the printing capabilities to remote system users by using DL as a front-end program and creating a program to perform the file transfer. DL was a good choice for this, since it already has the capability to pass a selected file specification to any target program that has a GETPARM named INPUT or FILES with keywords of FILE, LIBRARY, and VOLUME.

Unfortunately, the file transfer subroutine supplied by our vendor already had a GETPARM named INPUT, and the field names were not the same (i.e. FILENAME instead of FILE, etc.). Worse, several other fields were present on this screen and I did not want to accept their default values. Normally, I would have controlled this transfer program with a procedure, but a procedure would not be able to generate a GETPARM and, thus, accept the file specification passed from DL. The file transfer would have to be controlled by a program capable of performing the following tasks:

• Issue a GETPARM with a Parameter Reference Name (PRNAME) of INPUT

• Link to the file transfer program

• Pass the entered values from INPUT to the vendor's file transfer program through the PUTPARM function

The complexity of programming these calls to the GETPARM and PUTPARM subroutines made the entire project look unfeasible.

COBGEN to the rescue! Wang's COBOL generation tool makes GETPARM and PUTPARM programming simple (relatively). COBGEN prompts for the program's parameters and creates a shell program with all of the major elements defined, and it makes quick work of lengthy GETPARM, PUTPARM, and SORTCALL argument lists. The idea of using a code generator when complex calls are necessary is not new; programmers in the IBM mainframe world rarely hand-code those gnarly calls to CICS, and Microsoft Windows programmers can take advantage of a number of toolkits to simplify their application building.

If you have avoided including GETPARMs into your programs because of the complexity of doing so (as I have), read on.

Defining the process

Before attempting a program version of the file transfer, I wrote a prototype using Procedure language to check the syntax requirements. This procedure was run manually and typical files transferred. When I was satisfied with the results, the listing became my design document.

Next COBGEN was run. The specifications for the file transfer program included the following:

• Output file specification: The file, library, and volume of the source file to be created.

• File control: Any workstation, print, or data files to be used. In this case, no files were needed.

• Source Creation Options: Special features in the generated source file, including a FIGURATIVE-CONSTANTS section, date logic, GETPARMs and PUTPARMs, program links, and file sorts. The GETPARM, PUTPARM, and LINK options were selected.

• PUTPARM specifications: The type and related fields of PUTPARMs to be issued to the file transfer program. The prototype procedure showed what was required.

• LINK specifications: The link type, program file specification, and cancel exit options.

After all of these specifications were entered, the source code was created in seconds.

Results

Is that all? Not quite; the documentation for COBGEN is honest in describing the output as a "shell program". All of the major data items are defined, but the PROCEDURE DIVISION code needs the attention of a programmer and frequent reference to the VSSUBS Reference (Wang publication number 715-0599).

In the GETPARM data definitions, COBGEN provides three keywords - enough for the purpose of this program - but does not assign field names or initial values to them. The field locations are initially set to the first available row in column one, and no PF keys have been enabled.

Other changes to the program:

• The main paragraph was changed to reflect the actual PERFORM and control structure of the paragraphs below.

• The PRNAME and field names for the GETPARM were added.

• The keywords were changed from type A (alphanumeric data type) to L (limited alphanumeric data; suitable for file names, etc.).

• PF16 was enabled and set to exit the program if invoked. The variable GETPARM-AID-CHAR - the data item that receives the value of any PF key pressed - was used to branch to the program exit.

• The values entered in the INPUT GETPARM were passed to the appropriate PUTPARM fields.

The entire generation and modification process took a half hour and produced operational program code. Clearly, program generation is of value when complicated external references are involved.

The finished program can be used from the DL utility by entering the program name in the space at the bottom of the screen, tabbing to the print file to be transferred, and pressing PF9.

Conclusions

Procedure language offers simplicity and easy visibility, but programs allow more sophisticated decisions and self-sufficient operation. The effort required to create such programs can be reduced through the use of code generators and boilerplate. Either solution can be effective in some circumstances. Utility programs can be made much more effective with the addition of GETPARMs and linked programs. COBGEN can help simplify the task of creating such programs for COBOL users.