0

I've installed DB2 11.5.7 (and 11.5.8) on my Windows 10. I've created SAMPLE DB (using db2sampl).
When I'm trying to connect to this DB through ODBC it hangs on connection stage (I have to kill process).
It doesn't matter either connection establishing from my x86 application (C++) or from ODBC Data Source Administrator (32-bit).

Screenshot

  • On screenshot above I just pressed button "connect".
  • ODBC Data Source Administrator becomes Not Responding and fully utilize 1-2 CPU cores
  • It happens not each time, but it hangs in 98% attempts. Sometimes I'm lucky, but it's enough to relaunch ODBC Data Source Administrator (32-bit) and connection hangs again.

If I launch ODBC Data Source Administrator (64-bit) - connection always success.

Some additional info of my machine:

On all other machines which I tested no any similar problems.

What I tried:

  • Input correct and wrong user's password - hangs in both cases
  • Perform it on Windows 11 - connect hangs
  • Perform it on Windows 10 - connect hangs
  • Perform it under Virtual Machine (VMWare) with guest Windows 10 - connect hangs
  • Connect to remote DB2 Server - connect hangs too
  • Connect to this machine from another - another machine connects successfully
  • Tried DB2 versions: 11.5.7 and 11.5.8 - on both connect hangs
  • ODBC Data Source Administrator (64-bit) - connects successfully

I expect success connection from ODBC 32-bit.

5
  • If the symptom only exhibits on a single Computer, and only with the 32-bit driver, when used by a 32-bit app (like the 32-bit verison of odbcad32) then a full uninstall and re-install might alter the symptom (taking care to fully verify which options got installed, and whether any unusual events got placed in to the installation log files). Otherwise I would suggest using Microsoft's procmon on the 32-bit odbcad32 and filter only for failure results , and verify whether the Db2-server is getting the attempt(diaglevel 4) or not. In other words, try to narrow down the problem further.
    – mao
    Commented Jun 19, 2023 at 15:40
  • @mao, thank you for direction. I tried re-install, install on Windows 11, on Windows 10, also on Virtual Machine with Windows 10 - no luck. Currently looking with procmon by your advice, seems no any critical failures, but sure need investigate more detailed.
    – Dmytro
    Commented Jun 20, 2023 at 18:19
  • Unfortunately no any additional failures was catched by procmon or db2diag tools.
    – Dmytro
    Commented Jun 21, 2023 at 7:53
  • Your aim is to discover where it is looping/hanging (i.e. in driver-manager, in clidriver, or in Db2-server). Procmon (without filtering) might help there. One key detail is the FIXPACK level of your Db2-components , to ensure it is at the MOST RECENT fixpack for 11.5. which today is 8 (i.e. 11.5.8.0), that should be you start point.
    – mao
    Commented Jun 21, 2023 at 7:57
  • Thanks @mao, I already found solution. You may see my Answer here.
    – Dmytro
    Commented Jun 21, 2023 at 12:11

2 Answers 2

0

Finally found fix myself :)

Accordingly to call stack from my C++ app and to process happened catched by ProcMon I was almost confident that hang happens inside icclib (it's by stack) and it's is a part of GSKIT.

So I decided to search in google about some hang problem related to GSK8 and voila I find this IBM reported issue:

IJ44774: GSKIT ISSUE WITH AMD EPYC FAMILY 25 PROCESSORS

Error description

Commands like mmcrcluster or mmaddnode may hang in GSKIT
layer on AMD EPYC family 25 processors.  A particular model
from family 25 that is known to hang in GSKIT layer is
AMD EPYC 7343.

Local fix

Add "ICC_SHIFT=3" line in
/usr/lpp/mmfs/lib/gsk8/Cicc/icclib/ICCSIG.txt
file on problem nodes.

...

Symptom:

Admin commands hangs

Platforms affected:

Linux OS environments

Functional Area affected:

Admin Commands, gskit
  • it's describes fix for Linux, But! in my case it's a Windows!

Path to ICCSIG.txt on Windows:

C:\Program Files (x86)\ibm\gsk8\lib\C\icc\icclib\ICCSIG.txt
  • I've just added ICC_SHIFT=3 at the end of that file and that's it!
0

Thank you for posting this. I ran into a similar issue after a client was forced into an emergency migration of our Data Warehouse platform to Azure following a data center meltdown.

Our scenario was slightly different, but the end result was the same. We were able to connect somewhat timely, but any query or catalog lookup with any sort of volume to the resultset would just get lost in the void. Small single row queries would return data ok.

My customer is running Azure Windows 2022 Data Center with IBM DB2 Client 11.5 x32/x64. (I also tried a 10.5 IBM client, with the same results).

What I found is that as the return packet size increased, response time went up exponentially.

The DB2 client has a tool called DB2Ping that is really useful for visualizing this. (Run from an elevated DOS prompt, run DB2CMD to open the DB2 Command line processor.) I created a batch file to run a sequence of increasing return packet size commands, you can run them from the command line, just be sure to do the connect first, and disconnect at the end (replace values in the with your values)

This is an easy way to determine if you too are having the packet loss/fragmentation issue:

DB2Ping SCript

When the return packet size was less than 1400 bytes, the results were as expected. As packets got over 1455, response time became erratic and slow.

Results

I located the ICCSIG.txt file in the DB2 Client install folder on the Azure server. There were 6. 3 of the files appeared to be placeholders for "missing files" according to the contents. 3 looked legit with #Don't change anything above here" comments. I edited all 6 files just to be sure.

Voila... we're back in business, query times to DB2 are as expected. Would love to be able to explain "why", but whatever this setting does, solved the issue for me.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.