After installation on Fedora 14 x86_64 of
ftp://ftp.boulder.ibm.com/as400/iSeriesAccess-6.1.0-1.0.x86_64.rpm.
1) Segmentation fault upon language specific DLL use

Description:
Whenever the ODBC connector attempts to get an error or warning
message, it loads a language-specific DLL and computes some offset in it.
This computation is buguous and results in a segmentation fault.

Remarks:
_ This fix has been obtained by binary code debugging and reverse assembly.

Definitive solution:
A real C++ fix ought to be applied by IBM to the original source code before
recompilation.
2) Connector returns 32-bit field lengths.

Description:
Upon reading a selected DB record, field lengths are returned on
32 bits only. This is probably due to the ODBC library change: the connector is
compiled for libodbc.so/libodbcinst.so with soname = 1, while Fedora 12
provides them with soname = 2. This indicates an ABI change (probably
motivated by the SQLLEN type change itself!) Some web forums advise to symlink
libodbc.so.1 to libodbc.so.2: this allows to load the connector, but does
not garantee it is functional.

Temporary solution:
Happily, Intel CPUs are little endian machines, so bytes of a 32-bit
integer are stored at the same offset as in the equivalent 64-bit value. The
values passed as input parameters to the connector are then interpreted
correctly (providing they fit in 32 bits), but output parameters have their MS
32 bits undefined. Some code must then be added in the caller after reading
a DB field to restore the MS 32 bits. Care must be taken to properly handle
the special negative value SQL_NULL_DATA (-1). The sequence to "repare" field
length should then be something like:

Of course, this solution must be applied in conjunction with the symlinks
mentionned above, and does not work with field larger than 4 Gbytes !

Remarks:
It is highly probable that other types are also affected by size changes. Those
have not been identified: a similar processing must then be applied to values
of these types by the caller.

Definitive solution:
A simple recompilation with libraries with soname = 2 will totally fix the
problem.
3) DB field input with truncation returns a wrong length.

Description:
When reading a DB record, bounded length storage does not reflect the effective
input size if the corresponding field has been truncated.

Temporary solution:
For character fields, always use bound buffers of a byte length of at least
four times the field character size: this will prevent truncation in all cases,
even if all characters are returned as 4-byte UTF-8 characters.

Remarks:
_ This problem as already been identified in the PHP context:
http://www-01.ibm.com/support/docview.wss?uid=nas1ac5658703ae5a78b862575440052cbda
http://bugs.php.net/bug.php?id=47133
but non-PHP applications are affected too.
_ IBM provides a workaround: ODBC connection keyword "DEBUG = 65536".
_ The connector probably returns the recommended size for the allocation of a
new buffer for the truncated field. It should instead return the effective
field byte size (since the truncation is not an error, but a warning).

Definitive solution:
Source code should be fixed by IBM accordingly.
4) The client "CCSID" keyword does not apply to SQL statements.

Description:
Submitting a non 7-bit ASCII SQL statement (a string with at least 1 byte
outside USASCII range) to the connector always fails unless the caller has
previoulsy called "setlocale(LC_CTYPE, <charset_name>)", <charset_name> being
the character set name used for the SQL statement.

Temporary solution:
Always call setlocale() accordingly.

Remarks:
_ The CCSID keyword properly applies to non-SQL data, i.e.: character field
values are translated into this CCSID upon reading. It should also apply to
SQL, since it is a nonsense to have a regular DB client dealing with two
different caracter encodings. In addition, SQL statement conversion is
performed by a deprecated standard function instead of the connector's internal
convertor.
_ In the 2.6 kernel era, default should be at least to use UTF-8.

Definitive solution:
IBM should fix the source code to use it's internal charset converter and the
CCSID keyword value for SQL statement conversion.
5) Connector is not interrupt-safe.

Description:
There are some code sequences in the connector that do not preserve so-called
stacked values from being overwritten by an interrupt (aka signal) handler.

Temporary solution:
Never use signals in a program using the connector, or at least disable the
signals before entering ODBC functions and re-enable them upon return.

Remark:
Bad code sequence can be identified by negative offsets from the stack
pointer: plenty of them occurs, mainly at function entries. As an example,
in /opt/ibm/iSeriesAccess/lib64/libcwbcore.so, functionZN6cwbINI12CurrentValueEPcS0 (C++ cwbINI::CurrentValue(char*, char*)) starts
with:

A signal interrupting the program just before execution of the instruction
at 464ca will likely destroy values stored by the two preceding instructions, by
the stacking needs of its own handler.

This error comes probably from a bad optimizing scheme in C compiler used to
produce the binary library: local storage initialization has been moved before
its allocation !

Definitive solution:
A simple recompilation with a fixed compiler should do the job.
CONCLUSIONS:
The above temporary solutions make the connector usable, providing you have
access to the calling sources and are able to recompile these applications. In
no way they will make it operational within an existing binary application that
already fails on the original ODBC connector.

Some of these bugs have been reported to IBM in april 2010: they promised to
release a new version in ftp://ftp.boulder.ibm.com/as400/ before june 15th 2010.
As of today (Aug 13) we are still waiting.

Since IBM provides this software freely to promote iSeries, pretends to
support it although never releasing updates, and will never be able to
provide this connector in sync with all available Linux distributions (even
with those pretended to be officially supported), I strongly suggest they
opensource this ODBC connector: the community members will then be able to
fix the problems, compile it for their favourite distribution and make it a
live product): the expected side effects will be not only an improved
usability, but also a better connectivity range, promoting IBM iSeries computers
without any additional cost for this company.

Questions:
_ When will we get an update (real date!) ?
_ What about opening the sources ?

Re: FIVE BUGS/CAVEATS IN THE ISERIES ACCESS ODBC CONNECTOR FOR LINUX X86_64

‏2013-10-29T19:05:48Z

This is the accepted answer.
This is the accepted answer.

Hi guys, I'd just like to let you know that we've fixed a lot of the problems you've been seeing with our 64-bit driver with the release of our IBM i Access Client Solutions (ACS) and Linux Application Package. ACS is the replacement for some of the iSeriesAccess family of products (emulator, data transfer, etc...). This product is all Java based, so it runs on Linux, Mac, Windows, etc...

To go along with this product, we've also released two application packages with native tools: on Windows this includes the .NET and OLEDB providers, the AFP printer driver, and the ODBC driver. On Linux, this is essentially just the ODBC driver. This ODBC driver includes all the fixes that were included in the iSeriesAccess 7.1 SP8 driver. Additionally, it has been built with a newer version of unixODBC to support full 64-bit parameters and we also now support Debian based distributions with the included deb files. We also plan to release service packs for Linux with this product, which is something I don't believe we ever did for iSeriesAccess for Linux.

Unfortunately, we don't have PPC support for this new product yet, but that will be coming with the next service pack (which should come out in the next month or so).

Re: FIVE BUGS/CAVEATS IN THE ISERIES ACCESS ODBC CONNECTOR FOR LINUX X86_64

Hi guys, I'd just like to let you know that we've fixed a lot of the problems you've been seeing with our 64-bit driver with the release of our IBM i Access Client Solutions (ACS) and Linux Application Package. ACS is the replacement for some of the iSeriesAccess family of products (emulator, data transfer, etc...). This product is all Java based, so it runs on Linux, Mac, Windows, etc...

To go along with this product, we've also released two application packages with native tools: on Windows this includes the .NET and OLEDB providers, the AFP printer driver, and the ODBC driver. On Linux, this is essentially just the ODBC driver. This ODBC driver includes all the fixes that were included in the iSeriesAccess 7.1 SP8 driver. Additionally, it has been built with a newer version of unixODBC to support full 64-bit parameters and we also now support Debian based distributions with the included deb files. We also plan to release service packs for Linux with this product, which is something I don't believe we ever did for iSeriesAccess for Linux.

Unfortunately, we don't have PPC support for this new product yet, but that will be coming with the next service pack (which should come out in the next month or so).

Also, FYI: due to unixODBC not correctly bumping the SO version when they updated SQLLEN to be 64bit at 2.2.14, our driver still binds against libodbc.so.1. Some distributions that ship 2.2.14 patched their packages to correctly bump the SO version and unixODBC 2.3.1 finally bumped the SO version. When running on distributions that ship with this updated SO version, you will need to make a symlink from libodbcinst.so.1 to libodbcinst.so.2. I'm hoping that we can fix this in the future.

Re: FIVE BUGS/CAVEATS IN THE ISERIES ACCESS ODBC CONNECTOR FOR LINUX X86_64

Also, FYI: due to unixODBC not correctly bumping the SO version when they updated SQLLEN to be 64bit at 2.2.14, our driver still binds against libodbc.so.1. Some distributions that ship 2.2.14 patched their packages to correctly bump the SO version and unixODBC 2.3.1 finally bumped the SO version. When running on distributions that ship with this updated SO version, you will need to make a symlink from libodbcinst.so.1 to libodbcinst.so.2. I'm hoping that we can fix this in the future.

IBM i Access Application SP 1 packages has been released to ESS. It should become available sometime this Friday. You can get it from ESS when it becomes available. If you have trouble finding it on ESS, see this document.

When it's available it will have the filename IBM_i_Access_Client_Solutions_-_Linux_AP_LCD8_2012_01.zip.

Re: FIVE BUGS/CAVEATS IN THE ISERIES ACCESS ODBC CONNECTOR FOR LINUX X86_64

IBM i Access Application SP 1 packages has been released to ESS. It should become available sometime this Friday. You can get it from ESS when it becomes available. If you have trouble finding it on ESS, see this document.

When it's available it will have the filename IBM_i_Access_Client_Solutions_-_Linux_AP_LCD8_2012_01.zip.

Re: FIVE BUGS/CAVEATS IN THE ISERIES ACCESS ODBC CONNECTOR FOR LINUX X86_64

Hi guys, I'd just like to let you know that we've fixed a lot of the problems you've been seeing with our 64-bit driver with the release of our IBM i Access Client Solutions (ACS) and Linux Application Package. ACS is the replacement for some of the iSeriesAccess family of products (emulator, data transfer, etc...). This product is all Java based, so it runs on Linux, Mac, Windows, etc...

To go along with this product, we've also released two application packages with native tools: on Windows this includes the .NET and OLEDB providers, the AFP printer driver, and the ODBC driver. On Linux, this is essentially just the ODBC driver. This ODBC driver includes all the fixes that were included in the iSeriesAccess 7.1 SP8 driver. Additionally, it has been built with a newer version of unixODBC to support full 64-bit parameters and we also now support Debian based distributions with the included deb files. We also plan to release service packs for Linux with this product, which is something I don't believe we ever did for iSeriesAccess for Linux.

Unfortunately, we don't have PPC support for this new product yet, but that will be coming with the next service pack (which should come out in the next month or so).

I'm seeing completely different results depending on the kernel + unixODBC versions (all of which are greater than the listed requirement).

Can we get a list of 'tested' requirements for this driver, such as: "Will work on Ubuntu Server 12.04 LTS, Centos 6.5 x86_64, Debian 7.3 x64" etc?

Simply stating the minimum required version of unixODBC seems to not be entirely useful.

I just tested on a fully up to date Ubuntu Server 13.10 box and it's segfaulting instead of complaining about the parameter count.

I also completely removed the 2.2.14 unixODBC that's shipped with the package list and instead compiled & installed unixODBC 2.3.2. All symlinks are available for the driver, it's pointing to the proper lib version, and still segfaults.

Re: FIVE BUGS/CAVEATS IN THE ISERIES ACCESS ODBC CONNECTOR FOR LINUX X86_64

I'm seeing completely different results depending on the kernel + unixODBC versions (all of which are greater than the listed requirement).

Can we get a list of 'tested' requirements for this driver, such as: "Will work on Ubuntu Server 12.04 LTS, Centos 6.5 x86_64, Debian 7.3 x64" etc?

Simply stating the minimum required version of unixODBC seems to not be entirely useful.

I just tested on a fully up to date Ubuntu Server 13.10 box and it's segfaulting instead of complaining about the parameter count.

I also completely removed the 2.2.14 unixODBC that's shipped with the package list and instead compiled & installed unixODBC 2.3.2. All symlinks are available for the driver, it's pointing to the proper lib version, and still segfaults.

The kernel should not matter in the slightest, since Linus is very adamant about not breaking userspace. Just because it shouldn't, doesn't it mean it can't, but it seems very unlikely to me. Likewise, unixODBC doesn't really do anything - it just forwards API calls to the driver and manages the driver registry. The only reason we require 2.2.14 and above is that the header files were updated to change some types and parameters to 64bit (SQLINTEGER -> SQLLEN) on 64bit. Conceivabley, you could compile your app against 2.2.14 and then run it on previous versions of unixODBC with our new driver just fine, wheras compiling against the old version and running against the new driver would yield issues.

I'd be really interested to see traces and core dumps of your issues, but you'll need to open a PMR for that.

The kernel should not matter in the slightest, since Linus is very adamant about not breaking userspace. Just because it shouldn't, doesn't it mean it can't, but it seems very unlikely to me. Likewise, unixODBC doesn't really do anything - it just forwards API calls to the driver and manages the driver registry. The only reason we require 2.2.14 and above is that the header files were updated to change some types and parameters to 64bit (SQLINTEGER -> SQLLEN) on 64bit. Conceivabley, you could compile your app against 2.2.14 and then run it on previous versions of unixODBC with our new driver just fine, wheras compiling against the old version and running against the new driver would yield issues.

I'd be really interested to see traces and core dumps of your issues, but you'll need to open a PMR for that.

As regards the `odbcConv_PreConvert_C_CHAR` stacktrace, I was having this issue through the PHP PDO ODBC interface through unix ODBC to IBM's i Access driver and this blog post fixed my problem. It was an upstream problem in the PHP source code. His fix is in the PHP trunk now, but only as of April 2014, which hasn't made it to the Ubuntu packages as of yet.

I just copied the `pdo_odbc.so` in his blog post over top of my own and it worked.

Anyways, the PHP POD ODBC may be your issue if you're seeing a `odbcConv_PreConvert_C_CHAR` stacktrace, but then again it may not.

Re: FIVE BUGS/CAVEATS IN THE ISERIES ACCESS ODBC CONNECTOR FOR LINUX X86_64

As regards the `odbcConv_PreConvert_C_CHAR` stacktrace, I was having this issue through the PHP PDO ODBC interface through unix ODBC to IBM's i Access driver and this blog post fixed my problem. It was an upstream problem in the PHP source code. His fix is in the PHP trunk now, but only as of April 2014, which hasn't made it to the Ubuntu packages as of yet.

I just copied the `pdo_odbc.so` in his blog post over top of my own and it worked.

Anyways, the PHP POD ODBC may be your issue if you're seeing a `odbcConv_PreConvert_C_CHAR` stacktrace, but then again it may not.