Any application providing the ODBC interface has the disadvantage of dealing with a myriad of driver libraries. The different ODBC driver libraries may have been compiled with different compiler versions and different compiler options. The ODBC driver library could be compiled with older or newer version of the platform compiler, besides having different compiler options set during compilation which might cause incompatibilities with the driver manager and/or the application that provides the ODBC interface.
One such incompatibility arises for 32 bit Solaris platform, for Infosphere DataStage 8.0.1. The problem is not manifested with 64 bit Solaris libraries and therefore with Infosphere DataStage 8.1 and above , so this article maybe a little late in coming.
ODBC drivers that are not fully ANSI compliant will not work correctly with Infosphere DataStage 8.0.1 which is 32 bit( The problem is not seen with Infopshere DataStage 8.1 and over as libraries are 64 bit and so ANSI compliant). They will mostly cause a sigsegv in iostream during loading or during connection. To be fully ANSI compliant the driver should be compiled with compiler option -compat=5 or equivalent. (refer to CC man page) Also the driver should not have a dependency/reference to any library that is non-ANSI compliant e.g libC.so.5 etc.
The problem is usually manifested by the ODBC Enterprise stage failing with SIGSEGV and dumping core.
e.g of Teradata provided ODBC driver version 12, 32 bit Solaris
=>[1] unsafe_ostream::flush(0xfef0ea30, 0x0, 0xfc360000, 0x0, 0x0, 0xfef0ea3c), at 0xfeeeb5dc
[2] ostream::flush(0x1, 0xffbfc768, 0x8, 0x8, 0x0, 0xfef0ea2c), at 0xfeeec744
[3] flush(0xfef0ea2c, 0x0, 0x15, 0xff1baa54, 0x2328, 0x2000), at 0xfeeebc58
[4] ostream::operator<<(0xfef0ea2c, 0xfeeebc54, 0xff1baa54, 0xff1ad1a8, 0x0, 0xfeeebc54), at 0x22cec
[5] APT_ProcessManager::executePlayer(0x15da94, 0xfddec7bc, 0x1b36c8, 0xfee8bdc8, 0xffbfcb38, 0xffbfcb54), at 0xfea62b7c
[6] APT_ProcessManager::executeSequentialPlayer(0xffbfd050, 0xfee3c5b0, 0xfee8c4e8, 0xff1b53c4, 0xfee8c1b8, 0xfee8eb0c), at 0xfea59530
[7] APT_ProcessManager::executeSequentially(0xfee8dcfc, 0xffbfd1ac, 0x18123c, 0x3c100, 0x2, 0xffbfd460), at 0xfea57c04
e.g of Sybase IQ provided ODBC driver 32 bit Solaris.
The problem occurs due to the driver not being ANSI compliant like the Teradata ODBC driver or having a dependency on a non-ANSI compliant library like libC.so.5 e.g the Sybase IQ ODBC driver.
To make the driver ANSI compliant, it has to be compiled with -compat=5.
To check whether the driver is ANSI compliant
If the mangled names start with __0 (double-underbar zero), the code was compiled in -compat=4 mode. Example: __0FDfooi
If the mangled names start with __1 (double-underbar one), the code was compiled in standard (-compat=5) mode. Example: __1cDfoo6Fi_i_
This test was easily done for the Teradata ODBC driver since it was not ANSI-compliant itself, but
sometimes it maybe harder to determine whether there is a compatibility issue e.g the Sybase IQ ODBC driver which itself had correct mangled names, but had a dependency on libC.so.5 which is not ANSI-compliant.
One such incompatibility arises for 32 bit Solaris platform, for Infosphere DataStage 8.0.1. The problem is not manifested with 64 bit Solaris libraries and therefore with Infosphere DataStage 8.1 and above , so this article maybe a little late in coming.
ODBC drivers that are not fully ANSI compliant will not work correctly with Infosphere DataStage 8.0.1 which is 32 bit( The problem is not seen with Infopshere DataStage 8.1 and over as libraries are 64 bit and so ANSI compliant). They will mostly cause a sigsegv in iostream during loading or during connection. To be fully ANSI compliant the driver should be compiled with compiler option -compat=5 or equivalent. (refer to CC man page) Also the driver should not have a dependency/reference to any library that is non-ANSI compliant e.g libC.so.5 etc.
The problem is usually manifested by the ODBC Enterprise stage failing with SIGSEGV and dumping core.
e.g of Teradata provided ODBC driver version 12, 32 bit Solaris
=>[1] unsafe_ostream::flush(0xfef0ea30, 0x0, 0xfc360000, 0x0, 0x0, 0xfef0ea3c), at 0xfeeeb5dc
[2] ostream::flush(0x1, 0xffbfc768, 0x8, 0x8, 0x0, 0xfef0ea2c), at 0xfeeec744
[3] flush(0xfef0ea2c, 0x0, 0x15, 0xff1baa54, 0x2328, 0x2000), at 0xfeeebc58
[4] ostream::operator<<(0xfef0ea2c, 0xfeeebc54, 0xff1baa54, 0xff1ad1a8, 0x0, 0xfeeebc54), at 0x22cec
[5] APT_ProcessManager::executePlayer(0x15da94, 0xfddec7bc, 0x1b36c8, 0xfee8bdc8, 0xffbfcb38, 0xffbfcb54), at 0xfea62b7c
[6] APT_ProcessManager::executeSequentialPlayer(0xffbfd050, 0xfee3c5b0, 0xfee8c4e8, 0xff1b53c4, 0xfee8c1b8, 0xfee8eb0c), at 0xfea59530
[7] APT_ProcessManager::executeSequentially(0xfee8dcfc, 0xffbfd1ac, 0x18123c, 0x3c100, 0x2, 0xffbfd460), at 0xfea57c04
e.g of Sybase IQ provided ODBC driver 32 bit Solaris.
=>[1] __lwp_kill(0x0, 0x6, 0x0, 0x6, 0xfc00, 0x0), at 0xfddc12a4
[2] raise(0x6, 0x0, 0xfdda4bb8, 0xffffffff, 0xfdde8284, 0x6), at 0xfdd5fe18
[3] abort(0xffbfbf10, 0x1, 0xfdd46964, 0xa8350, 0xfddeb298, 0x0), at 0xfdd40038
[4] ut_onsig_sig_handler(0x0, 0x0, 0x0, 0x0, 0xb, 0x0), at 0xfc5e5278
[5] __sighndlr(0xb, 0xffbfc3c8, 0xffbfc110, 0xfc5e4c80, 0x0, 0x1), at 0xfddc01dc
---- called from signal handler with signal 11 (SIGSEGV) ------
[6] ostream::opfx(0xfef0ea88, 0xfb06ea8c, 0xfc160000, 0xfef0ea98, 0x5f, 0x74328), at 0xff0ffab8
[7] operator<< <unsigned short>(0xfef0ea88, 0xffbfc5ec, 0xfef0ea88, 0x5e, 0xbc, 0xffbfbd6c), at 0xff138e94
[8] APT_StreamMessageStore::store(0xaa8b8, 0xffbfc5ec, 0x0, 0xa, 0xbc, 0x5e), at 0xff0de580
[2] raise(0x6, 0x0, 0xfdda4bb8, 0xffffffff, 0xfdde8284, 0x6), at 0xfdd5fe18
[3] abort(0xffbfbf10, 0x1, 0xfdd46964, 0xa8350, 0xfddeb298, 0x0), at 0xfdd40038
[4] ut_onsig_sig_handler(0x0, 0x0, 0x0, 0x0, 0xb, 0x0), at 0xfc5e5278
[5] __sighndlr(0xb, 0xffbfc3c8, 0xffbfc110, 0xfc5e4c80, 0x0, 0x1), at 0xfddc01dc
---- called from signal handler with signal 11 (SIGSEGV) ------
[6] ostream::opfx(0xfef0ea88, 0xfb06ea8c, 0xfc160000, 0xfef0ea98, 0x5f, 0x74328), at 0xff0ffab8
[7] operator<< <unsigned short>(0xfef0ea88, 0xffbfc5ec, 0xfef0ea88, 0x5e, 0xbc, 0xffbfbd6c), at 0xff138e94
[8] APT_StreamMessageStore::store(0xaa8b8, 0xffbfc5ec, 0x0, 0xa, 0xbc, 0x5e), at 0xff0de580
The problem occurs due to the driver not being ANSI compliant like the Teradata ODBC driver or having a dependency on a non-ANSI compliant library like libC.so.5 e.g the Sybase IQ ODBC driver.
To make the driver ANSI compliant, it has to be compiled with -compat=5.
To check whether the driver is ANSI compliant
$ nm mylibrary.so
Look at the mangled names in the output.If the mangled names start with __0 (double-underbar zero), the code was compiled in -compat=4 mode. Example: __0FDfooi
If the mangled names start with __1 (double-underbar one), the code was compiled in standard (-compat=5) mode. Example: __1cDfoo6Fi_i_
This test was easily done for the Teradata ODBC driver since it was not ANSI-compliant itself, but
sometimes it maybe harder to determine whether there is a compatibility issue e.g the Sybase IQ ODBC driver which itself had correct mangled names, but had a dependency on libC.so.5 which is not ANSI-compliant.
Thanks for providing the information on DataStage Online training. Online training have the benefits of being convenient, flexible and on your own ti
ReplyDelete