Finally, IBM has released a new version of this product. I would have commented it in thread at http://www.ibm.com/developerworks/forums/thread.jspa?threadID=340630&tstart=0 but this is archived and closed for answers. The current comment will thus refer to the mentioned document.
1) Segmentation fault upon language specific DLL use
This bug has been fixed in the new release.
2) Connector returns 32-bit field lengths.
This problem is still pending, as the soname for the odbc libraries has not yet changed. The recipe in the above document should then still be applied.
3) DB field read with truncation returns a wrong length.
Still pending. However, the DEBUG=65536 parameter is now also recognized by the 64-bit version of the ODBC connector.
Some more details about this problem:
a) If the (converted) text + terminator fits in the target field, the effective text length in bytes is returned.
b) If a truncation occurs without the DEBUG=65536 parameter, the ODBC connector returns 8 times the DB data length, without computing the true needed length as the ODBC spec requires. This behavior probably targets a reallocation of the field buffer that will never fail, whatever the effective data length is.
c) If a truncation occurs with DEBUG=65536, the buffer size in bytes is returned. BEWARE: since truncated data is null-terminated, this count includes the terminator, while this is not the case when no truncation occurs.
4) The client "CCSID" keyword does not apply to SQL statements.
Still pending. Nothing seems to have changed here.
5) Connector is not interrupt-safe.
Seems to be fixed. That is: the connector has been recompiled with a fixed compiler !
The procedure in the example does not exist anymore: I've searched (manually, so I may be wrong) if some equivalent bad procedure preamble occurs elsewhere and did not find any.
6) ibm5250 terminal emulator requires to find file /etc/X11/XF86config or /etc/X11/xorg.conf, but these are not mandatory/not needed anymore in recent versions of Linux.
7) ODBC input truncation may result in undefined bytes at end of data: Hard to explain, but an example will be much clearer:
_ Suppose you read a 3-char field containing "abé" (last character is e accute!) into a 4-byte buffer with translation to UTF-8.
_ The connector assumes there are only 3 bytes in the buffer that are usable for real data: the 4th is reserved to be sure a null terminator can be stored.
_ The connector stores "ab" in the 2 first bytes of the buffer, but does not stores the e-accute since it is coded as a 2-byte UTF-8 character that won't fit in the remaining buffer space: truncation occurs.
_ The null terminator is stored in the FOURTH buffer byte, leaving the 3rd byte undefined. That's it !!!
Please note also that the new release is NOT available from the free download FTP server, as was the previous version.
As a conclusion, one can see some light improvements in this new release, but the remaining problems and the fixing reaction time would IMHO, justify again the opensourcing of this product.
Any comments are welcome !