Posted by Frank Fillmore on August 5, 2009 under .NET, DB2 Education, DB2 for z/OS. Tags: .

I am teaching a DB2 Connect Problem Determination and Performance class next week (CF632) and had the occasion to learn something nasty from a student who will be attending.  Steve W. told me that his organization is running DB2 Connect Application Server Edition v9.5 and DB2 for z/OS v8 New Function Mode (NFM).  In this environment his .NET applications didn’t behave properly.  They failed with timeouts forced by the new SQL Interrupt Support on z/OS.  The QUERYTIMEOUTINTERVAL parameter was set to 0 seconds (no timeout – wait for SQL statements to complete execution before returning to the application) in the db2cli.ini file, so that the application should have been able to run to completion.  Unfortunately, he learned that .NET applications don’t honor QUERYTIMEOUTINTERVAL.

Here are Steve’s two – unappetizing – choices:

  1. His shop can apply the new DB2 for z/OS DSNZPARM APAR (specified in the SQL Interrupt Support link above).  Because of the APAR dependencies, this is not a simple PTF and will require lots of regression testing.
  2. He can have his .NET coders modify their code to set the CommandTimeout parameter in *all* of the .NET applications.  Probably some testing involved in making those changes, too.

Ouch.  So DB2 for z/OS CM and NFM added SQL Interrupt processing as a default that you need to PTF to disable and the override isn’t supported in that little bitty Integrated Development Environment (IDE) .NET.  Has anyone else been bitten by this?  Can IBM come up with a zap to disable the SQL Interrupt Support or find a way for .NET to honor QUERYTIMEOUTINTERVAL?

More on the db2cli.ini in an earlier post.

3 Comments so far

  1. S. Liu September 1, 2009 4:24 pm

    My problem is that I can not get timeout. No matter what value i set in QUERYTIMEOUTINTERVAL and CommandTimeout

  2. Craig Wahlmeier September 18, 2009 4:06 pm

    I just came across this change while implementing the V9.5 Client on our servers. I have been arguing with IBM for years that their intent to eliminate the DB2CLI.INI from use by the .NET provider was ill-advised. We no longer have a central place to control the behavior of the driver. Instead, IBM thinks it wise to hardcode those settings in either the connection string or as a property on the DB2Command object. Obviously, they do not have any of their own systems written in this language.

  3. Craig Wahlmeier October 19, 2009 10:59 am

    This is a huge problem for us. I cannot tell you how mad I am. I have been arguing with Brent Gross for years that the DB2CLI.INI is very beneficial. Now, he has succeeded in eliminating it. In his mind, we can just hardcode anything we need on the Connection string. Bullcrap. First, I will have to rebuild and redeploy hundreds of applications. Next, when IBM screws up the client and we have change its behavior, we will need to update our apps again. Remember DISABLEUNICODE=1? Why does PATCH1 and PATCH2 exist? Anyone have trouble with timestamps, (MAPTIMESTAMPCDEFAULT=1)? This is a disaster for us…

Leave a Comment