The Steamroller Effect Flatten files with CONDENSE
From "VS Workshop",  Access to Wang, December 1990
[ Prior Article ]     [ Return to the Catalog of articles ]     [ Next Article ]

The aging Wang File Management Utilities provide a large variety of options for those wishing to manage their data needs without programming. I have covered the other members of the File Management group (CONTROL, REPORT, DATENTRY, INQUIRY) in prior topics; only the humble CONDENSE utility remains untouched. While certainly not a program that everyone will need, CONDENSE fills an important gap in the group by allowing reporting from complex file structures.

This month I will cover CONDENSE by presenting a real-life question: How does one merge information from differing record formats in the same file without writing a program?

What does CONDENSE do?

The CONDENSE utility is designed to create a single data record type from a file with multiple record types. It reads and interprets differing record types in a specified file, selecting fields from each record type and merging information into a common buffer. The merged information is written when triggered by conditions within the file, such as the presence or absence of specific characters.

Many existing applications use multiple record types. An example is a Purchase Order file where the information for the headings is stored in one record type, followed by any number of detail lines for each line item. The advantages of this type of file structure include flexibility (any number of line items may be specified) and the need to open only one file. One disadvantage is that Wang's File Management Utilities accept only one record type, so INQUIRY and REPORT cannot be directly used on such files.

CONDENSE allows the user to create a single record type from such files by creating and maintaining parameter files that specify the format of incoming and outgoing data. When a condensed file is required, CONDENSE requests the input and output file information and the parameter file to be used. The file is merged according to the specifications of the parameter file and placed in the location specified. An associated CONTROL file is also created for the output file.

The following items are needed before a CONDENSE parameter file can be created:

• A CONTROL file for each record type specifying all necessary fields.

• Knowledge of specific character combinations that uniquely identify each record type.

• The names of the fields in each record type that are to be included in the condensed file.

• The size and contents of any pad fields to be included in the output file.

• The name and location of a User Exit program, if desired.

An example: the CONFIG data file

I recently had need to produce a listing of workstations that identified their location on various Input-Output Controllers (IOCs) on our machine. The listing was to be sorted by workstation type and port location, and also include the device number.

Since Wang's GENEDIT utility is the only reliable source for such configuration information, I decided to use its print file as my data. However, the format of this report consists of differing information presented in several different formats - in other words, different record types. This meant I was unable to use a simple CONTROL file and REPORT definition to extract information as shown in prior columns (see the July 1990 and November 1990 issues of Access to Wang for details).

I discovered that CONDENSE performs the very task I needed. By creating the CONTROL files for each record type and constructing the parameter file, I am now able to recreate my specialized workstation report - or any other report - from the GENEDIT report information. (The locations of fields within the record types are shown in Figure 1, below; Figure 2 shows the selection criteria.) Once a single record format is created, a simple REPORT file is all that is necessary to report the information.

The Output Record Definition selection criteria at the bottom of the selection screens offer the means to control the contents of CONDENSE's buffer. In this case, the first record type (the IOC number) is retained indefinitely; the second type (individual devices) is moved to the buffer and the contents written AFTER this move. The RESET parameter is unnecessary in both cases, since each record found will overlay the previous contents. (See Wang's documentation of CONDENSE in the File Management Utilities Reference (publication 800-1308) for other examples of record type selections and buffer control.)

I did encounter some problems with the process, though. The record type selections were not reliable until I converted the original print file into a normal consecutive file, due to the variable-length records in all VS print files. This conversion is now performed using the CREATE utility within a procedure.

A perplexing aspect of CONDENSE is that the resulting CONTROL file produced for the output does not perform correctly with the CONTROL utility; in fact, it will send CONTROL into DEBUG! This proved true even with the latest versions I tested of the CONTROL and CONDENSE programs (version 2.01.00 of CONDENSE; version 5.00.02 of CONTROL). In spite of these difficulties, the CONTROL file delivered the results I needed within REPORT.

Wang's documentation for CONDENSE is unusually bad, but it does attempt to explain the control and use of the buffer.

Other uses for CONDENSE

CONDENSE could also be considered a data conversion tool for those considering "flattening" their files into more modern table structures. The process of producing normalized data structures - crucial for use of data base management systems - can also result in improved performance and reduced redundancy in applications developed in third-generation languages. Consider it part of your file manipulation toolkit.

Figure 1: Field Locations for Conversion of a GENEDIT Report Into Data

Record type 1: IOC information

Record Type/Field name	Type	Location	Length
IOC number	Numeric	32	2