COBOL/DATABASE Conundrum

COBOL applications cannot tolerate data instability, inflexibility, and lack of security¡K, yet COBOL applications cannot justify the cost of moving to the RDBMS world that provides stability, flexibility, and security. This is the COBOL/Database conundrum; applications cannot afford to be without a database, and applications cannot afford to have a database.

COBOL was designed for data processing. COBOL applications are very data centric. It is about storing and manipulating data in a useful way. Therefore, the data is very important, and cannot be corrupted, or lost. Relational Database Management Systems (RDBMS) as the name implies, are all about data processing. In fact, SQL itself was originally designed by IBM to support the COBOL language; therefore, there should be very few COBOL programs that do not use SQL! Yet the majority of COBOL applications still do not have data storage that matches the strengths of the language. It is frustrating that the integration of these technologies often has a prohibitive cost.

The reason for this is based on assumptions that were made when RDBMS systems were first made available for COBOL. These assumptions included the following:

Data Design Problems
As RDBMS developers looked at COBOL code, they noticed that not all files were relational. Some programs used a single file, with multiple redefines for different types of data within that file. Data was stored where there was room, not always close to related data. Relational databases work the best when data is designed in a relational manner (not storing the customer information with every order, for example). Also, databases have additional syntax for performing complex data retrievals that are not supported in languages like COBOL.

The end result of this conflict was that changes had to be made in the COBOL programs in order to get the "perfect" synchronization between the code and the database. Therefore, it was assumed that Relational databases would work in NEW or completely REWRITTEN systems, where the coding was done according to the rules of the database. This assumption totally ignored the intelligence of COBOL programmers, who quickly started using file relations, setting up normalized data structures, all within the construct of the COBOL file structures. So, COBOL shops ended up going in one of two directions. The first was to redo the application utilizing the syntax of databases (SQL). The second was to utilize the theory of relational data, but keep it in COBOL files.

Implementation Costs
Implementation of an RDBMS was going to be expensive. Early RDBMS were very machine intensive, so customers needed to purchase a much bigger machine. Converting programs required major code revisions, so development costs were expensive. This led to high product cost and support costs. If the new machine and development costs will be two or three million dollars, a database cost of two hundred thousand was not significant (only about 10% of the cost). Therefore, a high dollar amount for a database was not an issue.

This assumption ignored the fact that processing speed would become more affordable, and that much of the cost of conversion to a database was based on a lack of support for the applications that had been written using relational database concepts.

High-end Need for Data Protection
Who was going to be interested in moving to a database? As the cost was high and the resource commitment was high, then only large Data Processing centers could afford the change. Critical functions such as OLTP (On-line transaction processing) were typically used in the largest companies (with budgets that could afford the larger systems). The rest of the computing world still worked on a batch process, where any failures in data storage would be corrected by re-entry of the data after reloading the tapes. Smaller companies only had their systems up during normal office hours, and had the entire night to backup the day's work, etc.

This assumption was based on a very old way of doing business. Every company today (no matter the size) has critical data. All companies want to work in multiple time zones, have an access on the web, or allow for orders to take place at all hours. This means that very few companies will be satisfied with applications that run 12 hours or less per day. Therefore, the market for database should include ALL companies, not just the companies with large computers in elevated rooms.

Believing in the Re-invention of the Wheel
After the initial databases were put on the market, and the large companies made the conversion, new languages came into focus. They had new concepts (objects, functions, syntax styles, etc.). Some graphical coding technologies (4th Generation languages or 4GL) seemed to do away with the need for any syntax at all. Simply create your database, push a button, and you have a complete, working, business application. They promised to revolutionize the world. Database vendors were very quick to put in support for those languages. As these new technologies were implemented, and applications were developed, the database would become the center of data processing.

This assumption was based on the idea that most applications would be rewritten or replaced, by new technology. In most cases, this assumption was correct. But COBOL had been used to develop very complex and stable applications. Many companies who attempted to convert from COBOL to another language spent millions of dollars on projects that ultimately failed. The COBOL system remained, but was unable to connect to the database.

Conclusion

When RDBMS systems were first implemented, they did not consider the value of a solution that supported robust data processing applications (COBOL), without requiring costly rewriting. They also did not consider the value of complete, robust programs that fulfill business processes and have evolved over time to become a critical part of the business focus. This problem still exists with most database vendors. CASEMaker noted this problem and developed a version of our database to resolve the implementation costs of moving to a database, building a satisfactory solution to the database conundrum.