Highlighted
Absent Member.
Absent Member.
969 views

Visual Cobol 2.2 for Java: which persistence layer?

Jump to solution

Hi,

I'm an SW architect and we are moving our legacy cobol to Visual Cobol under Jboss.

This legacy application has a custom persistence layer which is generated using a custom tool.

Which are my options if I want to remove this custom persistence layer?

Hibernate? OpenESQL?

Isn't there something like hibernate for Cobol?

Thank you,

Mats

0 Likes
1 Solution

Accepted Solutions
Absent Member.
Absent Member.

Hi Mats,

Sounds like an exciting project, bringing the best of two different worlds together.

In terms of traditional COBOL mechanisms for persisting data, as you point out, you have OpenESQL as one option. This allows your COBOL program to use embedded SQL statements in the program to store and retrieve data contained within an RDBMS using JDBC.

But you also have traditional data file access using sequential or indexed files. COBOL has built-in support for using data files and is the most common data storage approach for procedural COBOL applications.

So depending on your data requirements, either of these approaches may well be sufficient.

If you’d prefer to use an object oriented model, this too should be possible. In this case though, you’ll probably find yourself generating Java classes using the persistence layer of your choice, say jOOQ or Hibernate, and then invoking these classes from COBOL to access data.

Procedural COBOL programs can uses classes easily enough, so you shouldn’t need to convert the COBOL programs themselves to OO – just invoke the Java object that is dealing with the persistence.

And assuming most if not all the existing COBOL are procedural programs, you’ll want to read up on our run-unit support if you’re using them in the context of an app server.

If you'd like to discuss further, please drop me a line at scot.nielsen@microfocus.com

View solution in original post

0 Likes
1 Reply
Absent Member.
Absent Member.

Hi Mats,

Sounds like an exciting project, bringing the best of two different worlds together.

In terms of traditional COBOL mechanisms for persisting data, as you point out, you have OpenESQL as one option. This allows your COBOL program to use embedded SQL statements in the program to store and retrieve data contained within an RDBMS using JDBC.

But you also have traditional data file access using sequential or indexed files. COBOL has built-in support for using data files and is the most common data storage approach for procedural COBOL applications.

So depending on your data requirements, either of these approaches may well be sufficient.

If you’d prefer to use an object oriented model, this too should be possible. In this case though, you’ll probably find yourself generating Java classes using the persistence layer of your choice, say jOOQ or Hibernate, and then invoking these classes from COBOL to access data.

Procedural COBOL programs can uses classes easily enough, so you shouldn’t need to convert the COBOL programs themselves to OO – just invoke the Java object that is dealing with the persistence.

And assuming most if not all the existing COBOL are procedural programs, you’ll want to read up on our run-unit support if you’re using them in the context of an app server.

If you'd like to discuss further, please drop me a line at scot.nielsen@microfocus.com

View solution in original post

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.