Skip to main content

Problem:

Customer is running a Net Express 4.0 application that uses the OpenESQL embedded SQL support to access a DB2 database on the mainframe.

The ODBC driver that they are using is the NEON (now DataDirect) Shadow Direct ODBC driver for DB2.

The application was running fine until they had to change some column descriptions in their tables from DECIMAL 2,2 to DECIMAL 3,3 which creates a host variable of PIC SV999 COMP-3.

After recompiling their applications with the new description any SELECT statement that accessed one of these modifed columns would cause an abend in the OpenESQL run-time of either a stack overflow or a memory write protection error.

Resolution:

After quite a bit of testing we found that their were two completely different issues that when used together would cause the run-time error to occur.

First, we tested this against other ODBC drivers including DB2 Connect from IBM and the error did not occur so we isolated the error to the NEON driver itself. The problem did not occur with SQL Server or Oracle drivers either.

Then we checked for differences between the return values of a SELECT statement from both the NEON driver and the DB2 Connect.

We narrowed it down to the NEON driver was returning a display value of 0.000 for a DEC 3,3 column instead of .000 which was returned by other ODBC vendors.

NEON only returned the digit to the left of the decimal when the value of the column was 0.

For the same column with a non zero value the data was returned correctly as .999 for example.

We also found that by turning off some Microsoft C/C 6.0 optimization switches when compiling the OpenESQL run-time the problem did this not occur even when 0.000 was returned.

Instead of Micro Focus removing optimization switches that would slow down the processing of all OpenESQL applications to fix a bug in the NEON driver, NEON agreed to fix the problem on their end.

NEON (DataDirect) fixed this issue with the ODBC Shadow Driver 6.1.1.680.

The customer tested with this version and concluded that the problem no longer occurred.

Old KB# 3939