Highlighted
Absent Member.
Absent Member.
566 views

Use Procob in Visual Cobol 3.0 with managed code (Java / JDBC)

Jump to solution

Hello,

I have a program with SQL which is compiled to Java bytecode. When I add the additional directives "p(cobsql) csqlt==oracle endp" in Project Properties > Micro Focus > Build Configuration, I get the error:

    * CSQL-F-048: Cobsql is not supported for use with managed code.

Instead of p(cobsql)... I added the directive SQL(PROCOB). Then I get the error:

    COBES0121S SQL(PROCOB) is only valid with SQL(DBMAN=ADO)

After adding this directive, the following error occurs:

  COBCH1572S ILREF directive has invalid type name 'MicroFocus.COBOL.SqlCLR.RunTime.dll'

which is not documentated.

According to the documentation this only works with .NET (http://documentation.microfocus.com/help/index.jsp?topic=%2Fcom.microfocus.eclipse.infocenter.visualcobol.vs2015%2FGUID-3492935C-7CBE-4055-A831-B2892E9EB056.html&cp=5_5_2_2_0_9_0_2_51).

Is it even possible to compile programs with Oracle SQL in Java byte code?

 

Best regards

Paul

 

 

 

 

 

SQL(PROCOB)

0 Likes
1 Solution

Accepted Solutions
Highlighted
Micro Focus Expert
Micro Focus Expert

RE: Use Procob in Visual Cobol 3.0 with managed code (Java / JDBC)

Jump to solution
Oracle's Pro*COBOL precompiler is only supported in native code. Oracle has not released a version that works with either .NET or Java byte code.

If you are moving to managed code the only option available is to use the Micro Focus OpenESQL preprocessor with either SQL(DBMAN=ADO) if using .NET or SQL(DBMAN=JDBC) is using JVM.

The SQL(PROCOB) directive provides a certain level of compatibility with some of the unique features of Pro*COBOL but currently it is only supported when compiling for .NET so when using SQL(DBMAN=ADO).

The level of complexity to migrate between native programs written to use Pro*COBOL and managed JVM programs using OpenESQL depends on what Oracle extensions have been used in the native code. OpenESQL supports ANSI standard SQL so most of these Oracle extensions may cause problems.

You can see what Oracle extensions are being used by compiling your native Pro*COBOL programs using the Pro*COBOL directive ANSI which should cause it to flag all non-ANSI extensions that it finds.

View solution in original post

0 Likes
1 Reply
Highlighted
Micro Focus Expert
Micro Focus Expert

RE: Use Procob in Visual Cobol 3.0 with managed code (Java / JDBC)

Jump to solution
Oracle's Pro*COBOL precompiler is only supported in native code. Oracle has not released a version that works with either .NET or Java byte code.

If you are moving to managed code the only option available is to use the Micro Focus OpenESQL preprocessor with either SQL(DBMAN=ADO) if using .NET or SQL(DBMAN=JDBC) is using JVM.

The SQL(PROCOB) directive provides a certain level of compatibility with some of the unique features of Pro*COBOL but currently it is only supported when compiling for .NET so when using SQL(DBMAN=ADO).

The level of complexity to migrate between native programs written to use Pro*COBOL and managed JVM programs using OpenESQL depends on what Oracle extensions have been used in the native code. OpenESQL supports ANSI standard SQL so most of these Oracle extensions may cause problems.

You can see what Oracle extensions are being used by compiling your native Pro*COBOL programs using the Pro*COBOL directive ANSI which should cause it to flag all non-ANSI extensions that it finds.

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.