The COBOL & SQL Challenge

Do you need simultaneous access to data using standard COBOL file I/O routines and SQL? The very nature of COBOL data and record definitions (including redefines) do not fit well into a traditional RDBMS (SQL based) paradigm of table and record definitions. To overcome this challenge, other vendors dynamically re-map COBOL's records into SQL records. The benefit of this approach is that the actual tables and records become native for SQL while the drawback is that the interface needs to convert data for every access performed by the COBOL applications. In addition, limitations on the types of operations that can be performed are imposed on the COBOL programmers. Because of the limitations of this approach, many programmers end up using a traditional, non-SQL solution for the COBOL application and make batch copies of records over to a relational database on a regular basis, with the effect of having duplicate and non-aligned data.

The approach FairCom took is different. Our engineers implemented the interfaces required by ACUCOBOL-GT and ExtFH using an ISAM approach that fits the standard COBOL approach to indexed files without the complications of a SQL table remapping. From the pure COBOL point of view, c-treeACE for COBOL is just a straight, more advanced "native COBOL" file system with no limitations imposed on the COBOL programmer. There is an interface between the c-treeACE SQL engine and the native COBOL data that performs the proper data conversion to make data available through SQL.

The advantage of this architecture is that, for the COBOL application, the data access architecture remains essentially unchanged. While the c-treeACE SQL engine must perform conversions on data access, the nature of SQL and in particular FairCom’s optimizer keeps the number of conversions quite low. Further, the simple data conversion FairCom applies is far more straightforward and efficient than the alternate approach of remapping COBOL tables into SQL tables.