Data Modernization

Many existing COBOL applications use traditional COBOL data files, such as flat files, VSAM, indexed or sequential files, etc., to store critical business information. In their day, this type of data storage did the job; however, with the introduction of relational databases (RDBMSs), the shortcomings of using traditional data storage have come to the forefront. Storing data in a relational database makes it much easier to customize reports and obtain analytics. Data in an RDBMS is typically easier to maintain, meaning less down time. In addition, using an RDBMS or data storage is an important step in building scalable application architectures.

Note: To view a list of supported relational databases, see Database Management Systems (DBMSs).

Once you have determined that adding a relational database into your application architecture is what you want, your next step is to consider your deployment options and select one that can best help you to achieve this goal.

Deployment Options

Enterprise Developer provides several solutions that enable you to update a COBOL application to use a relational database:

Embedded SQL: In your COBOL programs, you can replace file I/O verbs with embedded SQL (EXEC SQL). The Enterprise Developer OpenESQL feature enables you to do this. See OpenESQL for details.
OpenESQL provides the greatest flexibility for RDBMS support from within COBOL applications and is a widely used feature. However, for existing applications that are currently file based, updating a typical COBOL application to use OpenESQL is likely to represent a significant effort — potentially many person-years. In this scenario, Micro Focus provides alternative approaches you can use to achieve the benefits of a relational database in shorter time frames.
Micro Focus Relativity: The Relativity product provides an ODBC interface to your COBOL data files. The files essentially become a data source you can access from any client that uses ODBC or JDBC. This approach enables you to maintain data in COBOL data files without application change. In addition, you can take advantage of third-party tools, such as Microsoft Office and other software products, that provide enhanced reporting and analytics by accessing your COBOL data via the ODBC interface. For more information, see Micro Focus Relativity Documentation.
Micro Focus Database File Handler (MFDBFH).: Using this approach, application code remains unchanged. At run time, existing file I/O statements are translated to automatically store and retrieve data from your RDBMS instead of data files.
For optimal performance, MFDBH stores COBOL records as a binary BLOB in the RDBMS. To help you with your reporting and analytic needs, you can optionally create a database view to view the data within the BLOB.
See Micro Focus Native Database File Handling for details.
Micro Focus Database Connectors (DBC): This approach is similar to MFDBFH in that COBOL programs remain unchanged, and data is automatically stored and retrieved from an RDBMS rather than data files. DBC differs from MFDBFH in that COBOL fields are stored in individual columns within the database table instead of as a single binary BLOB.
While the DBC approach does provide more flexibility in how data is mapped into a table, it is less optimal with regard to performance. MFDBFH offers the most optimal performance; however, a precise comparison on performance between these two approaches it is not practical as each COBOL application is unique and mileage will vary.

Choosing the Best Option

The following provides guidance on how to choose the best deployment option for your COBOL application:

Data files: Data files offer the highest performance when accessed locally by the application, but at the cost of reliability and scalability. Data corruptions can occur due to hardware failure and can result in extended outages while data is recovered. Moving data remotely or putting in measures to mitigate failure can impact performance.
Embedded SQL: Choose embedded SQL if you can reasonably update the application within acceptable time and cost constraints. With any move from files to RDBMS, expect a loss of performance in the application as data is accessed over a network.
Relativity: If your main objective is to simplify access to COBOL application data by third-party applications, Relativity is a good choice because it requires no change to the application, and data remains within existing files. If you actually need COBOL data in an RDBMS for other reasons, and you cannot reasonably update the application to use ESQL, consider using either the MFDBFH or DBC approach.
MFDBFH: If you need to move data from files into a database rapidly, MFDBFH offers the best performance. However, this solution does not allow data to be updated outside of the COBOL program, and it is less flexible with regard to how COBOL fields are mapped in the table view. If these issues are important, consider using the DBC approach instead.
DBC: If you require finer control over how COBOL fields are represented in an RDBMS table, or you require the ability to edit the data outside of the COBOL program, this is likely your best option.

Performance Considerations

Performance is often the biggest concern when migrating data from files to an RDBMS, and you need to get an idea of the affect it could have on your application. As each application is different, precise comparisons of performance are not practical. That said, we recommend that you use these guidelines to help you make a decision:

Because batch applications are traditionally I/O heavy, migration of data to an RDBMS can have a significant effect on performance.
Online applications can lose performance in this type of migration, but this loss is minimal and often goes unnoticed by end users.
For applications that scale up as the number of users increases, RDBMS performance typically outperforms file access, and runs even more quickly when accessed over a network or via Fileshare.
You can help to mitigate performance concerns for MFDBFH- and DBC-based applications by introducing code changes that optimize database access.

Comparison: MFDBFH vs. DBC

	MFDBFH	DBC
Supported Databases	PostgreSQL SQL Server including Azure SQL DB2 LUW Oracle	ODBC SQL Server DB2 LUW Oracle
License model	Core or concurrent user metrics. Development tools included as standard within development products, but separate license required to run application.
Technical approach	BLOB-based storage with separate key columns. Views can be added to provide field-level visibility.	Field-based approach with individual columns corresponding to fields within the record.
Performance	Typically provides higher performance range.	Offers greater flexibility on field mapping.
Editing support	Views are read only.	Fields can be edited with caution.
Cloud	Tested with Cloud service provider databases such as AWS RDS and Azure PostgreSQL.	Offers generic database access using ODBC for on-premise scenarios.
Connection can be shared with an existing RDBMS connection	Yes for XA connections, but no for all others. By default, MFDBFH local connections maintain their own cache. However, Oracle can be optionally configured to use either an OCI connection or session pooling.	No for all connections.
Data file editor support	Yes, in version 8.0 and later	No
Supported by Enterprise Server and PACs	Yes	No
Arrays, ODOs, and redefines behavior	Applies only when a view has been generated. ODOs are not supported in Views.	Creates a separate column for each array element.
JVM	Yes, in version 10.0 and later	Yes, but incorporates native code and is therefore not a pure managed-code solution.