(Originally posted 2007-05-18.)

As you probably know this year’s UKCMG conference in June 25-27, Whittlebury Hall, Northants.

I noticed when I read the agenda yesterday 2 things:

• Glenn Anderson’s being worked awfully hard. He’s a great speaker so do make the effort to attend his sessions.
• There’s a BOF session on each evening – just before the entertainment.

So I rang Laura at UKCMG up and offered to run a BOF. I got a “that’s highly irregular to book one beforehand 🙂 but a great idea” response from her.

So here’s what I’m proposing…

z/OS and Mainframe Performance Instrumentation BOF

As performance folk we quite often run into frustrations with the performance data, most notably SMF. I could articulate quite a few of those myself. Similarly I’ve found limitations in what the IFASMFDP SMF Dump Program does. Accordingly I’d like to gather a “wish list” of such items and discuss them with the customers who I know are at UKCMG. I’d hesitate to call them “requirements” as this isn’t a formal requirements-gat>hering session. (I have no formal remit for this – but I do have the ear of a number of key developers.)

And I’d obviously like to continue the dialogue – perhaps at other conferences, but certainly by conventional means.

On the Monday I will’ve talked about CPU and Memory instrumentation. That ought to get people thinking.

So please bring your ideas – and perhaps have a think about it beforehand. And feel free to contact me to “put stuff on the agenda”, though I have no formal agenda for this BOF.

And see you at Whittlebury Hall in June!

(Originally posted 2007-05-16.)

I’m reminded of this white paper on XCF Performance from Joan Kelley and Kathy Walsh. It’s a good read and has been recently updated.

It does also remind me that there are “D XCF” subcommands that give information that isn’t in the RMF data (SMF 74 Subtype 2). We process these records in our consulting and I’m getting considerably more familiar the underlying data.

(I also had a situation recently where large messages went through the coupling facility, whereas the standard messages had no opportunity to do so.)

(Originally posted 2007-05-12.)

Now I know why, as previously reported here, there’s a new power meter on the HMC. See this blog entry and the links from it for more details of the “Big Green” energy efficiency initiative.

And this goes way beyond the “packets of grass seed” campaign of last year – which highlighted the already available energy-saving characteristics of the mainframe.

(Originally posted 2007-05-12.)

Here’s a nice BSOD from a ticket machine on the Nürnberg U-Bahn. 🙂

(Originally posted 2007-05-09.)

Whenever I talk about zIIPs and zAAPs I’m reminded of Zip Zap miniature radio-controlled cars. But (to get past the censors I have to say) zIIPs and zAAPs are not toys.

Here’s an extract from a post on MXG-L that Bernie Pierce made. (I reproduce it with his kind permission.)

If there is contention for the local lock, the cross memory local lock, the CMS lock or any other suspend lock, units of work that are zAAP or zIIP eligible will be dispatched on a standard processor as they are given the lock in periods of contention for the lock. When the lock is available, this processing does not apply; it applies only when the requestor is deferred due to lock unavailable. This overrides the IFAHONORPRIORITY=NO option. In extreme cases this may be an indication of possible scalability issues if the MIPS consumed by the application are expected to increase significantly in the future. One application I examined recently had so much local lock contention that one third of the zAAP eligible time was consumed on CPs with IFAHONORPRIORITY=NO. I would not be too concerned about 2-3%.

The customer asking the question to which Bernie responded obviously had 2-3% of the eligible work running on general-purpose engines (GCPs).

I think it’s worthwhile tracking this with the appropriate SMF 72 (Service-Class level) and SMF 30 (Address-Space level) instrumentation – but not to be too paranoid about it. It’s another example of where you need to dig below the marketing material to understand what’s really going on. And, through the life of zIIPs and zAAPs we’ll all learn a lot more about how they work and how work is scheduled on them.

A comment that may get me in trouble: The way zIIPs and zAAPs work has gotten complicated (to my mind) to the extent that I wonder how many people really know what’s going on and how to manage them.

The state of the art evolves… I’m told that if there were (hypothetically) to be a similar control to IFAHONORPRIORITY for zIIPs , the same considerations would apply to zIIP when NO is selected as for zIIPs.

(Originally posted 2007-05-08.)

Occasioned by some recent enhancements to MXG I thought it high time I talked about a couple of Coupling Facility commands that DB2 Version 8 can take advantage of:

(And thanks to Barry Merrill for the MXG information and the sample data I’m using here.)

MXG Version 25.04, May 7, 2007 provides support for these enhancements.

Coupling Facility Level (CFLEVEL) 13 introduced the WARM and RFCOM commands. These batch up pages for both the Write And Register process and the Read for Castout process. The former is for when pages have to be written to the coupling facility and the latter is for when pages are written out to disk by the castout owner at castout time. They’re intended to be more efficient than their single-page analogues.

DB2 still does single page actions – where appropriate.

DB2 Statistics Trace (SMF 100 in this case) provides instrumentation:

On the Castout side:

QBGLCM      RFCOM*REQUESTS*FOR*MULTIPLE*PAGES          3964
QBGLCR      RFCO*REQUESTS*FOR*SINGLE*PAGE              1900
QBGLRC      PAGES*CASTOUT                             31638

Using the above MXG variables, the number of pages castout using RFCOM is 31638 – 1900 or 29738 or 94%. The number of pages read for each RFCOM is 29738 / 3964 or 7.5.

Similarly one can do arithmetic with the WARM and WAR statistics:

QBGLMW      WARM*REQUESTS*FOR*MULTIPLE*PAGES           8066
QBGLWP      PAGES*WRITTEN*BY*WARM                     85449
QBGLWS      WAR*REQUESTS*FOR*SINGLE*PAGES             85714

Actually these last two numbers look suspicious: One might suspect that the number of WAR requests was 85714 – 85449 which actually is exceedingly small. Assuming the names are right (and they do reflect what’s in SDSNMACS) then one can conclude about half of the pages written were written by WAR and half by WARM (which is credible). The average number of pages written per WARM command is 85449 / 8066 or 10.6.

These are useful statistics as they show how these two CF commands (WARM and RFCOM) do make things more efficient by batching up requests. The other thing is I expect there will be conditions that prevent WARM and RFCOM from batching to this degree. Things in the category of “trickling”, for example. It might change the way we recommend configuring buffer pool and GBP thresholds.

I’d like to hear from other sites about their numbers. Especially the WAR / WARM ones.

(Originally posted 2007-05-08.)

Thanks to Margaret Koppes of the European Patent Office for this picture of me and Glenn Anderson hard at work at the “main tent session” 🙂 in München:

(Originally posted 2007-05-02.)

I’ve just submitted my three presentations for this great conference:

• Much Ado About CPU
• Memory Matters in 2007
• DB2 Data Sharing Performance For Beginners

UKCMG is – for me – a great chance to catch up with customers, vendors and others in the industry. Its prime focus is Performance – multiplatform in fact – but we always have a thumpingly good showing of mainframe and DB2 topics. And this year IBM is a Platinum sponsor, which might explain why we have a nice booth for me to hang around. I wonder what our freebies will be. 🙂

And the website for UKCMG is UK Computer Measurement Group.

(Originally posted 2007-04-27.)

Hmmm: IBM press release on the gameframe.

I’d like to see a lot more detail on this before I go “whoopie!” but it does sound like an intriguing idea. It would be the first “specialty” engine to actually feature different hardware. Reminds of me of the 3090 Vector Facility but it’s really nothing like it.

And at this stage there’s nothing about what will actually be shipped.

Still, I’m happy to see this because:

• Someone’s getting to have fun like this in the mainframe world.
• Hosting gaming servers (for example World of Warcraft) and Virtual Worlds (for example Secondlife) is an interesting and rapidly growing niche.

Update November 2007

First, here’s another developerWorks blogger’s take on the “gameframe”.

Second, according to the keynote at UK GSE Conference in October, we’re talking more “adjunct processor” than “specialty engine”. So more akin to Crypto than to zIIP.

Third, I’m thinking SMF 70 is going to have to evolve again to cope with this. At least that’s what I’d argue for.

But then nothing’s been announced beyond the original announcement. So we’ll just have to wait and see.

Update May 2008

I sat in an internal presentation a couple of days by my good friend Carl Parris in Poughkeepsie – who is leading the technical side of the project. I think the “gameframe” is in great shape and it’s highly likely I’m going to have some practical involvement with it in the early days. I’m frankly psych’ed. 🙂

(Originally posted 2007-04-26.)

I was pleasantly surprised to see my conference evaluations so soon – given the European System z Technical Conference was only last week. Very professional to have the feedback straight away.

All the people who filled in the evaluation forms – and that exceeded 50% of the attendees in every session – were very kind, I feel. Here’s what I learned:

I still talk too fast, and still have highly idiomatic English. So, given my international role, I’ll definitely have to work on both of those. My next conference is the “take no prisoners with UK English” 🙂 UKCMG conference in June. Then I hope to be at the North American version of this current conference in the Autumn – where maybe I’ll have to adapt my style again. I have friends who can tell me if my English is still too idiomatic, though maybe they’re unable now to act as cyphers for the average North American sysprog. 🙂

I wonder why I talk too fast: Perhaps it’s nervousness (and I’ll admit to just a tad of that), perhaps it’s having too much material (and maybe I should cut it down a little), but I’m hoping it’s just enthusiasm and a desire to throw in “the kitchen sink”.

On “the kitchen sink” it’s very difficult to know what your audience expects of you. Clearly, just parroting the manuals isn’t good enough. It’s taken me a while to realise I deliver more than that – and perhaps to relax about the “technical credibility” thing. And since these are my own foils (with one exception this time) I shouldn’t feel I’m just parroting some standard IBM Marketing material. But I’d hate not to deliver the “kitchen sink”.

And I realise that for some readers the term “kitchen sink” may be unfamiliar: If you “throw in the kitchen sink” it means you “throw in everything you’ve got”.

I’m not really agonising about this stuff, mind. But I do care. So thanks for the evaluations (which were pretty positive) and thanks for the evaluation comments.

Finally, do any other speakers feel this way? I guess they must do: I’ve had dear friends desperately worried about presenting and how they went down with their “public”.