DDF Row Counts Bug

(Originally posted 2006-03-30.)

One of the themes for Distributed access to DB2 that I talk about is Network Flows Optimisation, in particular ensuring that DB2 is taking advantage of such things as blocking…

When DB2 sends rows back to a DDF caller it can block them or return them singly (and indeed the degree of blocking can vary). Appropriate levels of blocking can reduce network traffic, optimising the bandwidth and reducing the network portion of the caller’s response time.

(This, of course, is important for applications such as Peoplesoft, Siebel and SAP R/3 accessing DB2 data residing on z/OS. Likewise ODBC (Excel?) and JDBC.

Now to the bug in the title…

The field QLACROWS in Accounting Trace (and QXSTROWS in Statistics Trace) tells you how many rows were sent to the DDF requester by DB2. The APAR says that on V8 this count is wrong.

But why should I care?

In our analysis we take the row count and compare that to the number of rows being served via Block Fetch. The difference, fairly obviously, is the number of rows being served as single rows. That is, potentially less efficient transmission.

So, not to have an accurate row transmission count is a bit of a pain – because it makes it more difficult to tell if we have a “non blocking” inefficiency in play. A shame because we could identify from Accounting Trace which application (and, potentially, user) is failing to block.