OpenESQL Comp-6 Variable

[Eric_Boatman]

Is there an easier way to convert a RM Comp-6 to something that OpenESQL would recognize. The error I get is "does not have a suitable definition to be used as a host variable"

The only way I've gotten this to work is move it to a Non Comp-6 Field first (into a signed non-packed field for example) ... then using that variable.

I was hoping that CAST or CONVERT functions would work, but Haven't had any luck getting it to work, or I've just go the Syntax wrong.

Thanks for your help/insight.

Eric Boatman

[Chris Glazier]

What product platform and version number are you using and what directives are being set?
I can use a COMP-6 data item as a host variable for OpenESQL using SQL Server and I do not receive an error. I am testing with VC for VS 3.0 under Windows 7.

[Eric_Boatman]

Visual Cobol - 2.2 Update 1
Using Windows Eclipse - Compiling using DevHub/RSE to Linux.
MySQL Database.

$SET SQL(DBMAN=ODBC)
$set idxformat"21"
$set rm
$set ADDRSV"COMP-6"
$set COMP-6"2"
$set SETTINGS

02 TEST-VARIABLE PIC 99 COMP-6.

EXEC SQL
INSERT INTO Hints SET ID=:TEST-VARIABLE
END-EXEC.

I think I've answered your questions, ... if you have more feel free to ask.

[Chris Glazier]

The problem isn't the usage COMP-6 but it is that OpenESQL doesn’t support using unsigned packed decimal host variables.

If you add a sign to the picture it will work.

02 TEST-VARIABLE PIC S99 COMP-6.

Then it will be treated the same as a COMP-3 field.

[Eric_Boatman]

Can I override my existing, for instance in a RM File, to S99 Comp-6 and it read properly? and update to MySql properly?

[Chris Glazier · Accepted solution]

I would not think that would work properly as adding the "S" to the PIC would cause it to store a sign byte into the field. The DIALECT"RM" directive, "RM" directive and the ability to read RM data files was really put in place to provide compatibility to run existing RM applications "as-is". If you are looking at modernizing your application or taking advantage of Visual COBOL features such as OpenESQL then, if possible, you really should convert your application and data files to use Visual COBOL default mechanisms going forward. This would help avoid the situation of having an application that is a mixture of both old and new.

Your best bet to workaround this issue is to use a separate set of data items as host variables to interact with the database and move these between the database and your existing data items as required.

Thanks.