(Originally posted 2006-04-20.)

Here’s my first tip with the new UK90006 / UK90007 DFSORT PTFs. It’s an apparently minor enhancement that I think people will like…

• It leads to a more elegant syntactical expression.
• It is more maintainable – in the face of changing record layouts.

Suppose you want to search a file for a string in a particular position in each record and replace all matching instances with a different string. (I might do that to scrub an SMFID in SMF records to produce sample reports.) Without DFSORT’s Symbols support (which is ancient history now) you might have to code something like…

OUTREC IFTHEN=(WHEN=(4,5,CH,EQ,C'84484'),OVERLAY=(4:C'ABCDE'))

In this example the field you are searching in is a 5-character string beginning in position 4. Hence 4 appears twice in the statement.

NOTE: I’ve already used two functions that are much more recent than the introduction of Symbols: IFTHEN and OVERLAY…

• IFTHEN applies a BUILD (also know as FIELDs) or an OVERLAY clause to only the records that meet the IFTHEN condition. In this case

  4,5,CH,EQ,C'84484'

  specifies which field to search in.
• OVERLAY changes only the specified fields. In this case

  4:C'ABCDE'

  overlays just the 4-byte field we previously searched in. Prior to OVERLAY you had to explicitly specify all the fields you wanted to appear in the output record, even if only one was changed – as is the case here.

Now, that works pretty well – because of these two new functions introduced with PTFs UQ95213 / UQ95214 at the end of 2004. But suppose the format of the record changes. You would have to recode all such utterances for the new field positions. It would be much better to do it in one place. And that, in a nutshell, is the case for Symbols…

Continuing with our example, you might map the record with a SYMNAMES DD that points to the following definitions…

F1,*,1,CHF2,*,1,CHSKIP,1   F3,*,5,CH

If you work through these definitions you’ll realise that F3 starts at position 4 and is of length 5 bytes. So it matches our original example. Prior to UK90006 / UK90007 you could code:

OUTREC IFTHEN=(WHEN=(F3,EQ,C'84484'),OVERLAY=(4:C'ABCDE'))

and the IFTHEN clause is fully symbolic (ignoring the literal comparison string – which could itself be converted to a symbol.)

But suppose the data was reorganised so that this field moved. You’ll notice that still requires you to change the OVERLAY clause to replace the 4 with a different position.

With UK90006 / UK90007 you can now code

OUTREC IFTHEN=(WHEN=(F3,EQ,C'84484'),OVERLAY=(F3:C'ABCDE'))

and a reorganisation of the data just means changing the Symbols deck pointed to by the SYMNAMES DD. If you’re sensible this will be in one permanent file and so it’s just one edit (plus, of course, some testing).

What has changed is the ability to specify a position (for example for OVERLAY) using a symbol.

So, I think I’ve made the maintainability point. I think this enhancement also allows more elegant expression: You now refer to the field consistently by its symbolic name, rather than in two different ways in two different places.

As I said, it’s a minor enhancement. But one I particularly like – as I mess around with DFSORT a lot and little annoys me more than clunkiness of expression and poor maintainability.

One final point: I mentioned above that you could replace the literal string values with symbols. Here’s how to do it (in this example). Add two symbol definitions to the SYMNAMES DD:

OLDVALUE,C'84484'NEWVALUE,C'ABCDE'

and replace the statement with

OUTREC IFTHEN=(WHEN=(F3,EQ,OLDVALUE),OVERLAY=(F3:NEWVALUE))

and now you can change the search and replacement string values without changing all the occurrences of these strings in all your code – just in the one place.

(Originally posted 2006-04-20.)

As many of you know I like to beta DFSORT function PTFs. About once a year a new set of functions appears, many in direct response to customer requirements. Occasionally some of the enhancements are at my suggestion. 🙂

Yesterday PTFs UK90006 and UK90007 became available. (Being UK based it’s nice to see PTF numbers beginning with UK but I read no significance into this.) 🙂

You can read the user guide here.

I’m not going to duplicate what that document says here. But the enhancements are rather pleasing. What I will do, occasionally, is post examples of things that are easy to overlook in this announcement. As someone who’s played with the code over the past six months I think I’m well placed to do this.

And I expect Frank Yaeger (the DFSORT function developer) to be all over the web with this stuff shortly.

(Originally posted 2006-04-07.)

As of today I have a new job.

• I still work for IBM.
• I’m still UK based.
• I still do performance analysis with customers in the same way.

But some things have changed:

• I now work in Software Group, rather than what’s now called Global Technology Services.
• I now have a geographical territory that stretches from Rejkavik to Vladivostok, and from Stavanger to Cape Town. I would quite like to visit all of those. 🙂 Actually there’s a hole in the middle that isn’t mine. 😦 But then IBM organisation was always a little unfathomable. 🙂

So, in practical terms very little changes for those customers who already know me. In fact I might be able to be a little more responsive – in case you’re planning any unforeseen crises. 🙂 And I hope to be meeting many more (really interesting) customers in more far-flung places. I’m already told to expect to be able to do more presenting, writing and looking after user groups. So I think that’s all goodness.

So, what’s not to like? 🙂

(Originally posted 2006-04-06.)

I’m strongly considering writing a DB2 Data Sharing For Beginners presentation. In fact I have a proposal in to do just such a thing for the US z/OS Conference (in Orlando in October). Obviously that would be a presentation I’d like to take to eg UKCMG and the EMEA z/OS Conference next year.

Would this be of general interest?

When I say For Beginners I’m not entirely sure I mean that. 🙂

Certainly I’d like to start simple – with such things as the kinds of structures DB2 uses and also the various configuration options an installation has. But I think I also want to talk about such things as the detailed XCF traffic that Data Sharing causes and also the effect of Coupling Facility Duplexing. (Actually if I get fancy I’d like to talk about the new RFCOM (Read For Castout Multiple) and WARM (Write And Register Multiple) Coupling Facility commands that DB2 Version 8 uses.)

As you know I like to keep feet in both (DB2 and z/OS) camps so this presentation would come at it from both angles. (It would be hard to justify just looking at Data Sharing from just the z/OS or DB2 angles.

But mainly my personal slant on this will be from the instrumentation perspective – with some nice examples to illustrate a few points.

As readers of this blog probably are my target audience…

• Do you see this as a presentation you’d like to see someone put together?
• What would you like to see in it?
• Would you think a formal paper would be necessary? Or just the foils?

(Originally posted 2006-04-03.)

In this entry I talked about an APAR that fixed an issue with mixed farms of control units, where only some supported MIDAWs.

Here’s another APAR. This one could increase the performance benefit of MIDAWs.

APAR OA15556 changes the way IDAWs (Indirect Data Access Words) are placed in memory, relative to the CCWs (Channel Command Words)…

(M)IDAWs point at the data for the I/O and CCWs point at chains of them. This enables scatter/gather I/O processing from disparate ranges of real storage addresses. (There’s nothing new in this paragraph.)

The point of MIDAWs is that it enables more scatter/gather with each CCW and hence improves channel efficiency.

DB2 can pass up to 64 CIs (Control Intervals) to Media Manager. When it does the CCW and all the MIDAWs cannot fit in a single page. So you get 2 CCWs and hence less effective use of the (FICON) channel. NOTE:The second CCW cannot start until the first one has finished.

So APAR OA1556 splits the MIDAWs into a separate page from the CCW so it can all be done with one CCW, improving effectiveness./

(Originally posted 2006-03-30.)

Long ago the DB2 REORG utility traded memory for speed with SORTKEYS and SORTDATA. The latter caused the object being REORGed to be unloaded and externally sorted (eg using DFSORT). (SORTKEYS was similar but for the keys to REORG the indexes.)

This is fine if you have the memory to drive either large in-memory sorts or multiple parallel sorts. But sometimes you don’t.

APAR PK18059 for V8 introduces SORTDATA YES/NO to allow you to specify whether an individual REORG will use SORTDATA or not.

(Originally posted 2006-03-30.)

Just briefly, here are some Access Path fixes I’ve been meaning to talk about:

PK14923 QUERY COST ESTIMATE IS TOO HIGH IN SOME CASES

PK16521 ONE FETCH INDEX ACCESS (I1) NOT USED WITH DUPLICATE PREDICATES

PK15143 POOR QUERY PERFORMANCE WHEN SORT MERGE JOIN IS CHOSEN AND MULTIPLE JOIN COLUMNS ARE POSSIBLE OR COL=LIT EXISTS ON SMJ KEY

PK20229 POOR QUERY PERFORMANCE WHEN FETCH FIRST 1 ROW AND INDEX EXISTS WHERE ALL COLUMNS HAVE MATCHING PREDICATES BUT IS NOT CHOSEN

PK19398 POOR PERFORMANCE MAY OCCUR IF REVERSE INDEX SCAN COULD BE USED BUT IS NOT CHOSEN FOR A 1-FETCH PLAN

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

(Originally posted 2006-03-30.)

I present at conferences on what I call New World DB2 application performance, by which I mean such things as Stored Procedures, SAP R/3 and BW, Distributed (DDF) and JDBC. I do this because I think us mainframe performance people need to lead conversations on DB2 application performance that actually acknowledge what the installation is trying to do with DB2. Often it’s not the common or garden CICS or Batch application anymore. Instead it’s the new Data Warehouse or ERP system. And we need to be equipped for that.

Here’s a good example of a new thing installations will be doing with DB2…

APAR PQ91315 introduces the WORF (Web Services Object Runtime Framework) feature. Yeah, I know it should be WSORF but I don’t get to make up the acronyms. 🙂

WORF enables both DB2 V7 and V8 to support a Web Services Provider capability.

If you want a reasonable idea of what Web Services is look at A Web Services Primer. I guess the point is that DB2 is adding all sorts of new-fangled application support, including XML and things like this that are built on XML.

And it’s worthwhile knowing that WORF makes use of a Unix System Services hierarchical file system structure. And creating that is what the pre-conditioning APAR (PK19732) is all about.

(Originally posted 2006-03-10.)

A little off-topic, perhaps, but I’ve just installed the second Alpha of Lotus Sametime 7.5, IBM’s recently-previewed new instant messaging client.

I would’ve liked to have installed the first Alpha but I’ve been working hard on behalf of one of my favourite clients until yesterday. There’s that phrase again, Brian. 🙂

Actually, I am favourably impressed with 7.5, particularly as it’s based on an IBM internal IM client that grew like topsy over the past couple of years.

And I also today got round to installing Lotus Notes 7. The good news is it was no effort at all. The not so good news is I’ve yet to have much that’s new leap out at me. But then it’s only been an afternoon. 🙂