GSE Conference 2007

(Originally posted 2007-11-05.)

Last week I attended GSE Conference for the first time in a long while. And I’m very glad I did.

Let’s get the egotistical bit out of the way first…

I very much enjoyed presenting Memory Matters in 2008. If you’ve seen me present it before you might notice some minor tweakings. We learn as we go, don’t we. 🙂 As usual the challenge is “too much material”.

I attended a number of other presentations. For me the highlights were:

  • Fabio Massimo Ottaviani’s presentation on zIIPs and zAAPs. This gave me some new ideas for charts – though I think I have to get the hang of zIIP/zAAP normalisation factors before I can implement them.
  • Mike Duffy gave a good presentation on Sysplex Distributor.
  • John Campbell was great value, demonstrating (in a painfully practical way) 🙂 what it takes to deliver High Availability. “Don’t trust a machine you can lift” comes to mind. 🙂 His proper topic was “DB2 Availability”.
  • Scott Drummond took Bob Rogers’ (or is it Harry Yudenfriend’s?) 🙂 foils on “More Data” and ran with them. Actually I think I might steal the foils off all of them and add my own touches – probably to add in some DB2 perspectives. This would be a 3-way “crossover” presentation: z/OS / z9, DB2 and DFSMS / DS8000.

And it was great to run into many customer and vendor friends. Thanks to BMC for the pretty t-shirt 🙂 and to BluePhoenix for the USB hub. And it was nice to spend time with most of my unit and my manager Gerry. Almost a team meeting.

Anyhow enjoy the foils and (perhaps) tell me what you think of them. They will evolve.

Hackday4 and Referer URLs

(Originally posted 2007-10-27.)

I’m going to have to stop adding “(sic)” after every use of the word “Referer”. As in “Referer URL”.

The term itself comes from one of the standard HTTP headers. And therefore is somewhat fixed. Despite giving my “wetware spell checker” a pink fit on a frequent basis. 🙂

Anyhow, in this blog entry I talked about how I can – as standard – get a display of the URLs people come from to land on my blog. (And in a comment to the entry I said I’d put up (using a standard Roller macro) the list of such Referer URLs).

Well, yesterday was IBM’s fourth Hackday (known as Hackday4). The idea came from Yahoo – who’ve been doing a similar thing for a long time. IBM has had 4, spread over the last 18 months. I’ve participated in ALL of them. I have – pretty much permanently – tons of hacking ideas swirling around inside my head. THIS was not the first I had for this particular Hackday.

So, I took my firefox extension – unfortunately only likely to be available internally – and taught it a new trick…

When a developerWorks blogger is at their “Referer URLs” page it takes the list of URLs and analyses the ones that came from Google. (I may add Yahoo if I get a significant number of hits). If the hit from Google was a search I take 2 things from the URL:

  • The country (as part of the domain name, with the assumption that “www.google.com” is the USA).
  • The search terms used.

I do some counting and display the country list. Likewise the search terms list. The search terms list is a bit trickier as you can, for example get searches with “zos”, “z/OS”, “z/os” etc. TODAY I don’t take the slash out and assume they’re all the same thing. But I do assume “z/OS” is the same as “z/os”. And I do make some attempt to recognise when there’s an acronym…

If I see “icf” and then later on “ICF” the search term becomes “ICF” and the original (mixed case) version is discarded.

People sometimes put quotes in searches. Today I don’t handle that.

It’s been a fun “time-limited” hack. It would be nice to do more with it. And perhaps to find some other Roller-based blogging site that I could test it with. Then maybe I can ship an EXTERNAL firefox extension to the users of that.

And what does this all buy?

Basically, given that over 90% of my hits are direct (which probably mainly are “spiders”) it’s NOT that statistically significant. But it does tell me something about where in the world my readership is located. And also something about the things people are searching for when they stumble across my blog. So maybe what to write more about.

It’ll be interesting to see if any of the “webby” terms in THIS entry show up in the list.

More on Coupling Facility Async / Sync Thresholds

(Originally posted 2007-10-17.)

Following on from Coupling Facility Async / Sync Thresholds – They Are A’Changin’ I’ve been informed by Development there is a new improved write up on how the Dynamic Sync/Async conversion works in Chapter 6 of the z/OS Release 9: Setting Up A Sysplex manual. I’ve read it and it is VERY good.

One thing to pull out is that there isn’t just one threshold… There are different thresholds for Lock vs List and Cache structures, for Duplex versus Simplex (aka Non-Duplex), and by machine. The thresholds that have increased are not the ones for the Duplex case. Those stayed the same. (The thing that got me sight of the new documentation was asking what effect Duplexing had on the thresholds, by the way.)

Not coincidentally I was in a customer yesterday planning how we are going to measure a test with DB2 Data Sharing at a distance of over 20km. Part of that will be experimenting with turning off System-Managed Duplexing but not (we think) User-Managed Duplexing (aka GBP Duplexing). Without in any way betraying confidences I’ll see if I can write up the lessons we’ll have learned over the coming weeks and months.

So do take a look at the new description. It is really very good.

Coupling Facility Async / Sync Thresholds – They Are A’Changin’

(Originally posted 2007-10-13.)

APAR OA21635 is one of a rare breed: A change to the thresholds for z/OS’s automatic CF Request conversion. (I’m told this has only happened once before.)

If you recall z/OS Release 2 (in 2001) introduced a very nice function that automatically converts Coupling Facility requests from Sync to Async, based on thresholds. The purpose of this is to minimise the CPU cost for a coupled z/OS system, while still providing reasonable request response times:

  • With a synchronous request the requesting z/OS CPU (engine) actively spins, waiting for the request to complete. So a longer request service time would lead to a higher CPU cost for the coupled z/OS system.
  • With an asynchronous request the requester does not spin. But the response time is longer.

When I say response time I mean CF request response time, which may have little to do with actual application response times. But the two aren’t totally divorced.

(Requests that were originally Async don’t get converted to Sync, by the way.)

The big change came, as I say, in z/OS Release 2 where XES introduced a new algorithm, measuring response times and, based on thresholds, deciding whether to convert Sync requests to Async. This measurement is not done for every request, but rather once in a while. So we don’t have “nervous kitten” syndrome here. 🙂 I like algorithms that are responsive. I don’t like algorithms that are overly jumpy.

So, back to the thresholds:

Technology changes, so it’s appropriate to revisit the thresholds from time to time. APAR OA21635 is a result of this. To quote Development:

The synch/asynch thresholds have been recalibrated to better reflect current z/OS and processor technology. After installing the APAR, installations may see some asynchronous CF activity shift back to synchronous operations resulting in slightly improved performance for applications sensitive to these CF operations.

What you’ll see when you install this PTF varies, depending on your situation:

  • For requests using an IC link – obviously to the same-footprint – nothing’s going to change as all requests are going to be Sync unless the request was explicitly Async. Requests using an ICB link (to a nearby footprint are probably broadly similar.
  • For long-distance requests again nothing’s likely to change as the new thresholds would again suggest Async conversion as the norm.
  • For middle-distance (say less than 2km) links (ISC) there may be some change: More requests are likely to go Sync rather than Async. For some customers this category has been of concern. The shift in thresholds is meant to address it.

An interesting game I like to play is to compare request types to “local” and “remote” CFs, particularly with Duplexing. And, obviously, the response times seen. The simple case is without duplexing where “local” requesters get Sync requests in the main – at perhaps less than 50ms. And “remote” requesters get essentially Async requests, with a much higher response time, especially at distance.

Distance discussions are well informed by such analysis. As are Duplexing discussions. Which is, perhaps, the essential “take home” message of this post.

When implementing the threshold changes I would form a view of such things before and after applying the PTF. And I’d be interested to know how well it worked for you.

And remember there’s nothing essentially good or bad about Sync or Async. It all depends on whether the behaviour is appropriate for your scenario.

But I’m pleased that, once in a while, the thresholds are revisited. So I think this is a good APAR.

The “Gas Gauge” was indeed more than a gimmick

(Originally posted 2007-10-12.)

Back in April this blog entry incorporated a picture of the z9 HMC display that includes the “gas gauge” (or “power meter” if you prefer).

This press release details a rather more serious purpose for the thing. And thanks to John McKown for pointing out the press release in IBM-MAIN Listserver.

New Support for BatchPipes/MVS

(Originally posted 2007-10-11.)

As many of you know I’ve been very fond of BatchPipes/MVS (aka “Pipes”) down the years (17 to be precise). So I’m pleased to seeAPAR PK34251: ADDING BATCHPIPES SUBSYS SUPPORT TO TEMPLATE UTILITY describes some new support in the DB2 Load Utility (as driven by the Template utility) which makes it much easier to use with BatchPipes/MVS.

(For reference here’s the BatchPipes For OS/390 Version 2 Release 1 announcement letter.)

I can see a number of scenarios where the ability to load from a pipe would be handy, potentially speeding up the load. (Whether it actually does will depend on all the other factors that govern the Load utility’s speed.) The most usual scenario is an unload step – perhaps using a utility or SQL, some transformation, and then a (re)load. This might or might not be into the same DB2 subsystem, but probably won’t be into the same DB2 table. The unload could be piped into the transformation step. If the transformation step doesn’t involve a sort then all three – the unload, the transformation and the load – could conceivably be done in parallel. (If it does involve a sort then the sort’s input phase would be overlapped with the unload and the sort’s output phase with the load, leaving just the (usually small) intermediate sort merge phase not overlapped.) For what it’s worth DFSORT has been able automatically to detect pipes for input and output – for 10 years now. 🙂 When it detects a pipe it switches to BSAM to process it, rather than using EXCP. (BSAM and QSAM are the only supported access methods for Pipes – as well as for Extended Format Sequential data sets – whether striped, compressed or not.)

The referenced APAR description does a good job, I think, of discussing considerations when using a pipe to load the data from.

And now I’m off to edit the BatchPipes Wikipedia entry. 🙂

DB2 Version 9 – STATIME Default Decreased to 5

(Originally posted 2007-10-10.)

I’m in a session where we’re going through DB2 Version 9 migration considerations – and right now there’s a table on display with changes to DSNZPARM defaults.

One of real value is that STATIME has changed to 5 minutes from 30. Unless you’ve overridden it you should now get much better information at the DB2 subsystem level. This does, of course, mean 12 sets of Statistics Trace records an hour, rather than 2. But it does mean that for the “counter” fields subtracting the first from the last gives you a MUCH better view of hourly rate at which the counter increments.

I think it’s a long overdue change. Of course, if you’ve hardcoded the default 30 value then you won’t see the improvement. And if you’ve already dropped STATIME to 5 or (still better) to 1 then Well Done! (In my DB2 Performance engagements I always ask for STATIME to be dropped to 5 or 1 – and no customer of mine has complained about what results.)

DB2 Version 9 RLF – Not Just For SAP

(Originally posted 2007-10-10.)

Namik Hrle, the IBM Distinguished Engineer for DB2 for SAP, presented yesterday to an internal audience. (It’s the first time I’d seen him present and he’s a very dynamic presenter.) His presentation prompted me to download the Enhancing SAP by Using DB2 9 for z/OS Red Book. One item I’d like to pull out is the enhancements in DB2 Version 9 to RLF. RLF will cancel SQL execution for an application that uses too much resource (and you can specify how much resource that is).

What’s new in Version 9 is in the area of additional work qualifiers. In Version 8 the granularity is at the plan, package, collection, Authid and LU Name level. For distributed applications (those using DDF), these three qualifiers usually aren’t enough. In Version 9 additional qualifiers are recognised: Client workstation name, Client application name, Client userid and TCP/IP address.

While this RLF enhancement was billed yesterday as one of the 42 line items in Version 9 for SAP (and there were a further 53 for SAP in Version 8) I don’t think this one’s value is unique to SAP. For example, that rogue in the Chief Executive’s office who runs a huge DB2 query driven from Excel can be stopped in their tracks – with much more focused targeting. 🙂

So if you’ve tried to use RLF in the past to curtail runaway DDF work, and you’re looking for yet another reason to go to Version 9, consider the enhancements to RLF.

I May Not Know Who You Are But I Have Some Idea Why You’re Here

(Originally posted 2007-10-08.)

I don’t think you can see this information but I can see what are called “Referrer URLs” for hits on this blog. (The HTTP protocol defines a header that contains the URL you came from – when you clicked on a link.) Disregarding the several “Direct” hits – which tell me nothing – I see lots of referrer URLs with some information in them, such as:

  • Google, Yahoo etc searches.
  • Other blogs.
  • developerWorks routings.
  • Other referrers.

It’s nice to see the latter three categories – but it’s really the first that interests me. I can see, for example, search terms and sometimes the originating country or language. So it’s perhaps a little flattering to see “.fr”, “.in”, “.se” and “.it” in today’s sample. And, given I’m new to this whole “referrer” business, I’m looking at the search strings with interest…

One question I’m forced to ask is “did the visitor get what they came for?” For example, did whoever searched with “http://www.google.co.uk/search?hl=en&q=%22Memory+Matters+in+2008%22&btnG=Google+Search&meta=” and then clicked on a link to my blog get what they came for? They certainly didn’t get the presentation as a PDF. They might not have liked what I wrote that caused Google to generate a hit. But they followed the link. And what am I to make of THAT? I simply can’t know.

But seeing what it was that people searched for that led them here tells me what the purpose of my blog is. 🙂 “Wisdom of Crowds” springs to mind. This doesn’t mean I’m going to abandon writing about what I want to write about. But perhaps it gives me some clues as to what’s of interest and what isn’t. (What I don’t know is which entry caused the hit.)

This data is definitely interesting enough to make me want to write some analysis code to work out what the top search keys are each day. And I know a friend of mine publishes exactly that on her blog. (I think it’s a standard WordPress widget.)

The other thing, of course, is that I now know I have an audience. 🙂 But to repeat…

I don’t know who you are. So don’t be afraid to visit. 🙂

And to whoever was looking for Linda August and Joan Kelley I hope you’re glad you found me. 🙂