CAE/DOS (IP20881) v1.2 & SDK/DOS (IP20891) v1.2 FixPak APAR information ======================================================================= FixPaks IP20881, IP20891 ------------------------ APAR IC10321: CAE/DOS yield CPU to non-ODBC application with DB2YIELD OFF APAR IC10328: SQLSTATISTICS result in a syntax-error SQL statement APAR IC10437: sqln=0 & sqld>sqln in SQLDA for FETCH brings Server down APAR IC10451: CAE/DOS ONLINE HELP FOR LIST DATABASE IS WRONG APAR IC10798: SYSOWNER keyword is ignored if specified on connect string APAR IC10903: MS QUERY CANNOT ACCESS TO SYNONYM IN SQL/DS DATABASE APAR IC11014: GPF when a number of ODBC apps open/close connections intercha APAR IC12009: GPF in DB2W.DLL durinng connect from ODBC app APAR IX48568: Better estimate the size of a backup to an adsm server APAR IX52278: CLP truncates the results of a query and returns DB21018E. APAR IX54235: bind with grant does not commit APAR IX56697: APP terminates when appc session is killed (SIGUSR1) APAR JR08493: server does not return the fifth token in SQLERRMC field APAR JR08593: CAE/DOS 1.2 does not AUTOCOMMIT after SELECTs APAR JR08620: Problem Description APAR JR08633: SQLSTATE 7002 on a select from MS Excel with 1.2 and 2.1 DB2 APAR JR08705: log info in sqlofica at a lower level & check level 1st APAR JR08769: Issue t_sndis async. FixPaks IP20429, IP20431 ------------------------ APAR IC08974: Table name alias on AS/400 Previously the CAE/DOS client did not support the use of SYNONYM on an AS/400. This problem has been fixed, and will require that you rebind your databases. APAR IC09071: Yield on server connect using IPX/SPX Previously the DOS client, using IPX/SPX, would wait indefinitely for a response from a DB2/2 server that was not found. This caused the CPU to yield all other Windows applications that were running. The problem has been fixed. APAR IC09438: ODBC accessing graphic columns Previously, ODBC applications using the DOS client may have returned corrupted characters or trapped when accessing graphic columns in DB2 databases. This problem has been fixed. APAR IC09868: ODBC collections on AS/400 To access any collection in an AS/400 the keyword SYSOWNER, found in the ODBC.INI file, should be set to the name of the collection. This was not being retrieved properly, but has now been resolved. APAR IX46939: ODBC connection establishment When running DB2 applications in an ODBC environment, connection establishment dispatched Windows messages. If a user tried to issue a second connection at the same time as the first connection, reentrancy problems resulted. This fix now prevents this situation from arising. APAR IX46959: ODBC inconsistent result set Previously, if the ODBC API SQLStatistics was called more than once the second attempt would not return any information. This fix corrects the problem. APAR JR08276: ODBC NULL parameters for column name Previously, the SQLDESCRIBECOL API did not allow NULL parameters for the column name. This fix corrects the problem. APAR JR08456: Server interrupts with downlevel clients Previously an interrupt issued from a CAE/DOS v1.2, or SDK/DOS v1.2 client against a DB2/2 v2.1 (beta) or DB2/6000 v2.1 (beta) server was ignored when using the NETBIOS or IPX/SPX communications protocols. This fix corrects the problem. Other CAE/DOS & SDK/DOS Fixes Logon Security This feature was previously found in the DB2/2 v1.2 DOS/Windows client when the commands SQLLOGN2.EXE and SQLLOGF2.EXE were used. The CAE/DOS and SDK/DOS products previously had these commands, but no action was performed on the information entered. This has been fixed, and these commands now work with the following syntax: (a) Just type SQLLOGN2 and let the program prompt you for userid and password. or (b) Type "SQLLOGN2 userid" , no password is prompted or (c) Type "SQLLOGN2 userid *" , let the program prompt for password or (d) Type "SQLLOGN2 userid /p=password" NOTE: In using (d), the password will be displayed on the screen. Prior to the changes made to SQLLOGN2.EXE and SQLLOGF2.EXE, the userid and password were stored in one of 3 methods: 1) The environment variables DB2USERID and DB2PASSWORD. 2) Supply userid and password in .INI files. (ODBC applications) 3) Provide userid and password everytime a connection to a database was made. Hints and Tips: When using the commands SQLLOGN2 and SQLLOGF2 please be aware of the following features: 1) In the DB2/2 DOS/Windows client, SQLLOGN2 and SQLLOGF2 converted the userid and password to uppercase, since it only connected to DB2/2 and the OS/2 UPM (user profile management) only accepted uppercase userid and passwords. With the CAE/DOS and SDK/DOS clients the userid and password are kept as mixed case for connecting to other platforms, such as DB2/6000. 2) SQLLOGN2.EXE in the DB2/2 DOS/Windows client checked the syntax of the userid and password that it was supplied (ie. the first character was not a number). The SQLLOGN2.EXE that is supplied with CAE/DOS and SDK/DOS does not check the userid and password. 3) The userid and password are limited to 8 characters in length. 4) CAE/DOS and SDK/DOS still supports the original 3 methods of providing a userid and password to the server. The order of priority that is followed is: For non-ODBC applications: 1) logon via SQLLOGN2.EXE has highest priority 2) if logon is not performed via SQLLOGN2.EXE, then the environment variables DB2USERID and DB2PASSWORD are queried. For ODBC applications 1) ODBC-specific logon procedures have the highest priority. (ie. userid and password are stored in ODBC .INI files) 2) If logon is not performed via 1), then userid and password are retrieved from the information stored from SQLLOGN2.EXE. 3) If logon is not performed via 1) or 2), then the environment variables DB2USERID and DB2PASSWORD are queried. FixPaks IP20252, IP20253 ------------------------ APAR IC07930: Unequal Code Page Support This fix adds unequal code page support for European countries to the ODBC drivers. Users can now connect Windows CAE/DOS v1.2.0 clients to DB2/2 servers and through DDCS/2 to host databases. There had been no support for unequal code pages in the DB2/2 and DDCS/2 products. The codepage conversions that were required were between the following codepages: Server Client ------ ------ 437 819 (1004 in Windows) 850 819 (1004 in Windows) To invoke unequal codepage support: 1. Re-run DB2ODBC.EXE from the FILE pulldown menu on the windows desktop 2. Re-bind packages (section 1.2.3.1 of this file) 3. EDIT ODBC.INI, add to specific data source entry the following: TranslateDLL=x:\path\db2trans.dll TranslateOption=y (where x:\path\ is value of DB2PATH, and y is 850 or 437) APAR IC08006: Lotus Query Fails While connected to DB2/6000, the client did not handle code page specific queries from Lotus correctly. This fix corrects the problem. APAR IC08044: Detach from Novell Fileserver Previously, after the CAE/DOS client attached to the Novell fileserver to read the bindery object containing the network address of the OS/2 DB2/2 server, the client did not subsequently detach from the fileserver. This fix corrects the problem. Now, after reading the bindery object, the client remains attached only if had been previously attached to the fileserver, otherwise it detaches from the fileserver. APAR IC08045: Trailing Blanks ODBC Driver Previously, the ODBC driver passed trailing blanks in delimited identifiers, causing a syntax error in SQL/DS. This fix corrects the problem, the trailing blanks have been eliminated. APAR IC08183: ODBC Driver, SQL0199 The ODBC driver placed a scalar function in a VALUE statement, which produced an SQL statement that was not valid for DB2/2 v1.1 or v1.2. This resulted in the error SQL0199, "The use of reserved word '' following '' is not valid. Expected tokens may include: ''". This fix corrects the problem. APAR IC08287: DBCS ODBC/CLI Statement scanner "{" (Ox7B) For Double-Byte countries (ie. Japan), the CLI/ODBC statement scanner did not recognize the character "{" (0x7B) as the second byte of a double byte character. This fix corrects the problem. APAR IC08581: TCP/IP gives up control in Socket call TCP/IP gives up control of the CPU in a socket call, allowing concurrent multiple database connections, which can not be handled by CAE/DOS. We have replaced the default blocking hook routine with a non-yielding blocking hook routine. With this fix, the underlying winsock will not yield. APAR IX46939: TCP/IP is NON-BLOCKING The send function of TCP/IP is NON-BLOCKING, meaning that we are unable to verify that the entire buffer will all be sent in one send call. This resulted in the client hanging. This fix corrects the problem by checking for partial sends. APAR JR08119, JR08271: MSQUERY (Microsoft Office) Query Fails When constructing SQL statements with MSQuery (Microsoft office) there was a missing space in the statement causing an unexpected token error. This fix corrects the problem. Other CAE/DOS & SDK/DOS Fixes Fetching CHAR column with NULL entry Previously, if a buffer was bound twice, and a NULL entry from a CHAR column was fetched, it would generate an SQL error on the second fetch. This fix corrects the problem. Below is an example of the Scenario: SQLExecDirect( hStmt, "select c from t", SQL_NTS ); SQLBindCol( hStmt, 1, SQL_C_CHAR, ... ); SQLFetch( hStmt ); /* Non null value */ SQLBindCol( hStmt, 1, SQL_C_CHAR, ... ); SQLFetch( hStmt ); /* Null value returns SQL_ERROR */ *********************************************************************** ** ** ** (c) COPYRIGHT INTERNATIONAL BUSINESS MACHINES CORPORATION 1996. ** ** ALL RIGHTS RESERVED. ** ** ** ***********************************************************************