(Originally posted 2006-02-22.)

APAR OA14572 documents a problem where there is excessive SRB time and an increase in EXCPs for the index component of a VSAM KSDS accessed by RLS when two or more RPLs are adding records to the end of the data set.

(Originally posted 2006-02-22.)

APAR PK15454 documents an extension to DB2’s EXPLAIN function which makes correlation of the various tables involved much easier. This enhancement is used by Visual Explain but can also be used by people querying the tables EXPLAIN produces, in particular DSN_FILTER_TABLE and DSN_PREDICAT_TABLE.</p.

When you EXPLAIN a statement it produces rows in the well-known PLAN_TABLE table, but also in these other two tables (and some other lesser-known tables).

To quote from the APAR description a number of problems were fixed…

1. When an access path uses multiple index access, the output to DSN_FILTER_TABLE is ambiguous because the sequence number of a step in a multiple index operation is not available.
2. For an INSERT within SELECT statement, in DSN_PREDICAT_TABLE the TABNO can be ambiguous between the select and insert part of the statement.
3. The LITERALS column in DSN_PREDICAT_TABLE does not display SMALLINT properly.
4. Slow performance when running Explain on a query and DSN_DETCOST_TABLE is defined.

(Originally posted 2006-02-22.)

I’m deeply involved in a nice complex study at one of my favourite clients at the moment – so I’ve just come up for air for half an hour or so. So I’m catching up on blogging about interesting APARs.

So APAR PK15890 is my second SQL Access Path Enhancement of the day…

Take the case of a query like

SELECT T1.*
  FROM SYSADM.TP1 T1, SYSADM.TP2 T2
  WHERE T1.C2 = T2.C2
  AND T2.C1 < '2003-12-31'

where T2.C1 is the partitioning column of the T2 table.

Suppose further that Hybrid Join was the chosen access path and that T2 was accessed as the inner table via List Prefetch.

Prior to PK15890 Page Range screening would not be used to limit the scan of T2 to a subset of its partitions. In this example you’d want the only the partitions where the

T2.C1 < '2003-12-31' 

local predicate is true to be scanned.

The fix will be made available for both Versions 7 and 8.

(Originally posted 2006-02-22.)

APAR OA14839 documents Omegamon support for 2107 (DS8000) devices.

(Originally posted 2006-02-22.)

APARs OA14769 and OA14340 document changes to the SMF 30 record. Whether you call them enhancements or fixes depends on your perspective…

APAR OA14769 is marked FIN which means no fix is immediately available, but one is expected some time in the next 24 months. SMF30MES should be set to ’02’x whenever MEMLIMIT is explicitly coded in JCL, or in the SMFPRMxx member of parmlib, but if MEMLIMIT=0 is coded in the JCL or SMFPRMxx, the value in SMF30MES is incorrectly set to ’00’x.

APAR OA14340 handles better the case where EXCP counts overflow the field. (SMF 33 and 34 are also enhanced for the same condition.)

(Originally posted 2006-02-22.)

DFSMS APAR OA15034 documents a condition where some controllers support MIDAWs and other controllers don’t. Where a tablespace spans these two kinds of controllers this APAR is important.

MIDAWs (Modified InDirect Access Words) are a new channel programming construct on System z9-109 processors which can improve the efficiency of FICON channel programs and hence improve performance. I’ll be presenting on these at the z/OS conference in Dusseldorf 20-24 March.

(Originally posted 2006-02-22.)

First reported for DB2 Version 7 APAR PK17725 documents an enhancement to the access path for EXISTS (also NOT EXISTS) queries…

Previously DB2 performed DISTINCT processing, requiring a sort. Now the sort can be avoided as DISTINCT processing is no longer done.

Fixes will be made available for Versions 7 and 8.

(Originally posted 2006-02-07.)

If you are reporting on DB2 incremental binds, whether through DB2PE/DB2PM, some other reporter, or your own code you might find the number wrong. You know it’s wrong because it plain looks silly.:-)

APAR PK16637 describes just such a problem. Note: As of today the fixes are not yet available.

The significance of this number is that it represents additional CPU cost, elapsed time, and I/Os. So getting it right is important.

(Originally posted 2006-01-24.)

Today we announced the zIIP specialty engine for System z9 109. When I say we I had nothing to do with it, of course. 🙂 I’m in Global Services and we don’t make processors – we only tune them. 🙂

It seems to me zIIPs are going to be more significant than zAAPs. zAAPs (sometimes known as IFAs) are offload engines for java – and so are relevant to new-fangled workloads. I do know customers who have installed them, and others who have trialed them. Which reminds me I need to catch up with the two big trials I’m aware of. Here’s a link to one of them – with 13 zAAPs. But most customers don’t run tons of java on z/OS yet.

zIIPs, on the other hand, (sometimes known as SUPs) are going to be of interest to installations who:

1. Run DDF work against DB2. These include Peoplesoft, Siebel and SAP R/3. (The latter was rearchitected to use DDF for DB2 Version 8.) Also quite a few home-grown applications, including the dreaded Excel spreadsheet. 🙂
2. Do lots of IBM DB2 Utilities work.
3. Use DB2 Star Schema processing. These are most common in Data Warehouses, such as SAP BW.

Now, in my social circle are lots of customers doing 1. , quite a few doing 2. (but perhaps not burning much CPU doing it), and a few doing 3. (SAP BW users, mainly). So I conclude this is going to be really quite popular.

I have been in conversation with a number of developers and under the covers this looks a lot like zAAPs. Certainly in RMF you should expect to see the SMF 70 record (and reporting) treating them like zAAPs. But they do have their own processor pool (Pool 6) and their own sample counts, etc. So everything we learned about zAAPs appears to hold true for zIIPs.

And our code in PMMVS for processor analysis is going to have to evolve. Luckily we did a lot of work on this over the past two years. So this should be a natural extension of what we’ve already done.

And, naturally, I feel pretty good about assessing the scope for zIIPs – given the right data.

Finally, during the conversations on zIIPs I got to have some pretty nice discussions on things we could add to our instrumentation for processors in general. 🙂 That’s my bit of influencing Development done for the year. 🙂 But I can’t tell you about these neat enhancements right now. 😦 And anyway they will look better with some sample data than they would if I tried to describe them to you.