c-treeRTG COBOL Edition User's Guide

c-treeRTG Extended Data Definitions - XDD

To provide simultaneous access to the data through COBOL and SQL, c-treeRTG maps COBOL types into SQL types (and vice versa). c-treeRTG must know the structure of the records so it can provide the SQL schema required for this mapping.

COBOL does not provide the necessary information about record structures required by SQL. These must be presented from an external source. Some COBOL compilers can generate XFD files which define this record structure.

When an XFD is Available

c-treeRTG provides a command-line switch to ctutil utility to convert XFD files into an XDD (eXtended Data Definition) file. This file is in XML format and contains information about the data and index structures including: index definitions, record schemas, default field values, null field handling (an undefined concept in COBOL), behavior of data conversion errors, etc.

During the conversion from XFD to XDD, ctutil also accepts a "rule file" that contains instructions to customize the generated XDD file for specific needs (such as default values for fields).

When an XFD is Not Available: xddgen

For those compilers that do not provide a means to generate an XFD file, we provide the OpenCOBOL-based xddgen, which can create an XDD from the COBOL source code. See the xddgen chapter for more information.

Merging the XDD with the Data File

The information contained in the XDD is stored directly in the data file itself with no effect on COBOL access to the data. The XDD file is embedded into the data file using the ctutil ‑sqlinfo switch. After adding the XDD information to the data file, the ctutil ‑sqllink switch is used to make it immediately accessible through SQL.

Indexes

Any operation performed through SQL or from the application uses and maintains existing indexes for optimal performance. Because of the nature of some COBOL types encoding, a native RTG index may not sort as an SQL expects. FairCom DB SQL can still take advantage of these indexes to retrieve records while not using them for sorting. This architectural limitation does not have significant impact in practice because the SQL engine is able to build temporary index files on the fly when necessary and uses dynamic index techniques. In addition, SQL specific indexes can also be created and are fully compatible with both SQL and original RTG application usage.

Multiple Record Types

An interesting feature available with c-treeRTG is the ability to have multiple record schemas in the same data file.

A common programming technique for optimizing memory and storage was to combine multiple schemas into a single data file or table. Depending on some criteria, each record was interpreted using a particular application specific schema. This technique is a standard COBOL feature using REDEFINES. This, of course. contradicts strict relational requirements of SQL schemas. FairCom addresses this challenge by virtually presenting each application specific schema as a separate SQL table. This is accomplished by indicating in your data schema definition your same application specific rule determining which table each record resides. c-treeRTG does the rest.

Select statements on one of these virtual tables display only records matching the selected criteria. Inserts into these tables are checked for matching criteria.