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:
- 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.
- 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.