Visual Cobol 2.2 for Java: which persistence layer?

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

Parents
  • Verified Answer

    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

Reply
  • Verified Answer

    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

Children
No Data