Thanks Roberto for the suggestion. I have the DB2 v 7.2 client setup to use either Netbios or TCP/IP. I get the crash either way.
Based on the info from IBM on the issues of going to version 7.2 on Unix I installed the DB2 client version 7.1 on another machine (eCS 2.0) along with a version 3 ODBC driver manager. That works. The DB2 ODBC driver reports itself as ODBC version 3. It appears that one of the differences between DB2 v 7.1 and 7.2 is the ODBC driver was upgraded to version 3.52.
The conclusions at this point are:
1) if you have an ODBC driver manager at version 3 you can use DB2 client version 7.1 but not version 7.2.
2) If you have an ODBC driver manager at version 2.5 you can use either version of the DB2 client.
3) If you bypass ODBC and call into the CLI library directly you can call the ANSI version of the functions and it appears to work OK.
I am pasting some info from the DB2 site about ODBC and unicode. Based on the name, I believe the version 3 OS/2 driver manager is DataDirect. Earlier versions of driver managers can be DataDirect or Visigenic
stuff from DB2 site
--------------------------------------
DB2 10.5 for Linux, UNIX, and Windows
CLI applications that are ODBC-compliant can access a DB2® database through the CLI/ODBC driver in one of two ways:
linking to the CLI/ODBC driver library or linking to the ODBC driver manager library.
CLI applications can access a database by:
Direct access - An application links to the CLI/ODBC driver library and makes calls to exported CLI/ODBC functions.
Unicode applications accessing the CLI/ODBC driver directly should access and perform transactions against the
database using the CLI Unicode functions, and use SQLWCHAR buffers with the understanding that all Unicode data
is UCS-2. To identify itself as a Unicode application, the application must connect to the database using either
SQLConnectW() or SQLDriverConnectW().
Indirect access - An application links to an ODBC driver manager library and makes calls to standard ODBC functions.
The ODBC driver manager then loads the CLI/ODBC driver and calls exported ODBC functions on behalf of the application.
The data passed to the CLI/ODBC driver from the application might be converted by the ODBC driver manager. An
application identifies itself to an ODBC driver manager as a Unicode application by calling SQLConnectW() or SQLDriverConnectW().
When connecting to a data source, the ODBC driver manager checks to see if the requested driver exports the SQLConnectW()
function. If the function is supported, the ODBC driver is considered a Unicode driver, and all subsequent calls in the
application to ODBC functions are routed to the functions' Unicode equivalents (identified by the 'W' suffix; for example,
SQLConnectW()) by the ODBC driver manager. If the application calls Unicode functions, no string conversion is necessary,
and the ODBC driver manager calls the Unicode functions directly. If the application calls ANSI functions, the ODBC driver manager
converts all ANSI strings to Unicode strings before calling the equivalent Unicode function.
If an application calls Unicode functions, but the driver does not export SQLConnectW(), then the ODBC driver manager routes
any Unicode function calls to their ANSI equivalents. All Unicode strings are converted by the ODBC driver manager to ANSI
strings in the application's code page before calling the equivalent ANSI function. This might result in data loss if the
application uses Unicode characters which cannot be converted to the application's code page.
Various ODBC driver managers use different encoding schemes for Unicode strings, depending on the operating system:
Table 1. Unicode string encoding schemes by operating systemDriver manager
Operating system Microsoft Windows Linux and UNIX
Microsoft ODBC Driver Manager UTF-16* not applicable
unixODBC Driver Manager UCS-2 UCS-2
DataDirect Connect for ODBC Driver Manager UTF-16* UTF-8
* UTF-16 is a superset of UCS-2 and therefore is compatible
The DataDirect ODBC driver manager for DB2® can be used for connections to the DB2 database.
Restrictions
Complications arise when using the CLI/ODBC driver with the DataDirect Connect for ODBC Driver Manager
in the UNIX environment because of the use of UTF-8 character encoding by the driver manager. UTF-8 is a variable length
character encoding scheme using anywhere from 1 to 6 bytes to store characters. UTF-8 and UCS-2 are not inherently compatible,
and passing UTF-8 data to the CLI/ODBC driver (which expects UCS-2) might result in application errors, data corruption, or application exceptions.
To avoid this problem, the DataDirect Connect for ODBC Driver Manager 4.2 Service Pack 2 recognizes a CLI/ODBC driver and not
use the Unicode functions, effectively treating the CLI/ODBC driver as an ANSI-only driver. Before release 4.2 Service Pack 2,
the DataDirect Connect for ODBC Driver Manager had to be linked with the _36 version of the CLI/ODBC driver which does not export
the SQLConnectW function.