This article addresses the use of COBSQL/Pro*COBOL on Intel-/Alpha-based chips.

Problem:

• What are the byte ordering requirements for Pro*COBOL applications?
• How should I compile a Pro*COBOL which also interacts with CICS?
• Executing my Pro*COBOL application on Linux returns RTS114 against SQLBEX.
• Executing my Pro*COBOL application on Windows returns RTS114 against SQLBEX.
• How does the COBSQL MAKESYN option work?
• How should I use the Pro*COBOL COMP5 option?

Resolution:

Note: For more background on building Pro*COBOL applications on UNIX platforms, please refer to this KB article:

https://community.microfocus.com/microfocus/cobol/net_express__server_express/w/wiki/20446.building-and-executing-pro-cobol-applications-on-unix.aspx

Pro*COBOL and Byte Ordering

The Oracle client expects host variables along with parameters to Oracle API calls -- as generated by Pro*COBOL in the same byte order, or endianness, of the operating system that it is running on.

• Machines that store the integer value 2 as h"0002" are called big-endian machines.
• Machines that store the integer value 2 as h"0200" are called little-endian machines.

Intel and Alpha platforms are little-endian. The problem for COBOL is that variables that are of type COMP are always big-endian regardless of operating system but Oracle expects data to be little-endian. On Intel/Alpha platforms, if the wrong byte ordering is used, this can lead to RTS114 errors.

Full details on this can be found in Oracle documents, which can be found under the Oracle Metalink site, under documents 70245.1, and 70012.1. You need to have Oracle maintenance support in order to view these documents.

In order to ensure that host variables are correctly ordered, you can use either the Pro*COBOL COMP5 directive, or the COBSQL MAKESYN directive ; note well, that this is not the same as the Checker MAKESYN directive!

Problems can occur when you specify particular combinations of COBSQL's MAKESYN and Pro*COBOL's COMP5 options, as they can prevent conversion of host variables -- e.g. COMP5=NO NOMAKESYN -- which would lead to an RTS114. See section 4 below for details of (in)valid combinations.

Pro*COBOL "COMP5" option

If COMP5=YES:

• All data items defined as USAGE COMP are converted to USAGE COMP-5.
• All data items generated by Pro*COBOL itself will be declared USAGE COMP-5.

If COMP5=NO:

• The precompiler ignores host variables defined as USAGE COMP-5.
• Precompiled files generally do not run on either Intel or Alpha platforms.

On relevant platforms, COMP5=YES is the default in Oracle 8.1.7 and later.

COBSQL MAKESYN directive

Scope of this directive

COBSQL relies on a BEGIN DECLARE SECTION and END DECLARE SECTION to be coded, in order to use the correct scope for updating the definition of data items listed below.

However, explicit coding of those section markers is optional for Pro*COBOL, as of the Oracle 8i release.

If these clauses do not exist, then COBSQL will not change any host variables from USAGE COMP to USAGE COMP-5, which will cause errors when executing your application.

To force the user to explicitly code the BEGIN/END DECLARE SECTION clauses -- required for COBSQL to function correctly -- you can pass DECLARE_SECTION=YES to Pro*COBOL.

• If this option is passed, and all host variables are declared within those section markers, COBSQL will behave as expected.
• If no such section markers are coded, Pro*COBOL will generate errors against any host variable referenced within the application.

What the directive does

COBSQL operation can be a little confusing as there are 3 scenarios:

• Scenario 1: Default, i.e. neither MAKESYN nor NOMAKESYN are specified

  All data items, regardless of them being host variables or not, defined as either USAGE COMP or USAGE COMP-4 will be converted to USAGE COMP-5.

• Scenario 2: MAKESYN specified

  All host variables defined as USAGE COMP will be converted to USAGE COMP-5.

• Scenario 3: NOMAKESYN specified

  All data items are left as-is.

Valid/Invalid combinations for Intel/Alpha combinations

For Intel/Alpha platforms, the following table shows which combinations are and are not valid:

¹ You must use compiler directive (MAKESYN "COMP-5" = "COMP") to make this work. See the section Using CICS and Oracle below.

Using CICS and Oracle

CICS and Enterprise Server MTO expect any numeric parameters on EXEC CICS calls to be defined as USAGE COMP. This can clash with the requirements of Oracle.

If using Pro*COBOL and CICS within the same application, on Intel-order machines, you should therefore pass these directives:

p(cobsql) MAKESYN CSQLT=ORACLE8 END-C DECLARE_SECTION=YES COMP5=NO ENDP

Using Pro*COBOL directly

If you are bypassing COBSQL and using the COBOL product to compile the output of an Oracle preprocessor, you must pass COMP-5 data items to all Oracle calls.

Old KB# 3957