(Originally posted 2007-03-18.)

Here’s an interesting BBC News Article: Vehicle warning system trialled.

So let me see now, when we said the fridge would talk to the microwave – as everything would have an IP address – did we really envisage that they would Twitter? 🙂 Can you imagine “The Bloggings of an uncleaned fridge?” 🙂

And can you imagine what’d happen if my fridge started Twittering and next door’s microwave yakked back? 🙂

Seriously, I do like the “wisdom of crowds” element of cars talking to one another to relay traffic conditions. But I don’t like the idea (rather like programmed selling) that cars could all decide to take the same diversion? Or that one car could try to sucker the others into getting off its road.

So it might not just be humans that get smart enough to do this stuff.

And the reason I pick up on this peer-to-peer non-human stuff is because we’re used to central authority on things like weather, travel, road conditions… At least in 2 out of those 3 cars already pick up this information centrally. It’s a shift when it becomes peer-to-peer. Kinda like the shift from Web 1.0 to Web 2.0.

(Originally posted 2007-03-17.)

Here’s a useful contribution to the debate about Twitter: From a friend’s blog. There’s much mileage in the comments – which is where the action really hots up. 🙂

Actually her blog is in general a good read – but maybe I’m biased as she’s a friend of mine. She’s a Web 2.0 enthusiast with a great line in photos and original art. (If you want a business justification for reading her blog she’s a manager with IBM’s Rational division.)

(Originally posted 2007-03-16.)

Twice the “128GB” question has come up in newsgroups (the latest in DB2-L). This sort of thing freaks people out – so let me tell you what I know of the matter…

I was fortunate to attend the T3 for DB2 9 in February. This question came up in the context of some changes to DDF:

In Version 8 communication between DDF’s DIST address space and the DBM1 address space was via CSA (actually ECSA so above the 16MB line) and the Private Area. This had two major impacts:

• The CPU cost of moving data between the two address spaces (and I’m told there’s some reformatting, which adds to the cost).
• In extreme cases – large networks of heavy threads – chewing up of scarce ECSA and the DIST private area. (Thread “anchors” reside in the DIST address space and can become large, especially with the new, larger, communications buffer capability.)

So, in DB2 9, the interface between DDF and DBM1 was radically redesigned: Now the communication is done using a z/0S 64-bit Large Memory Object. This is in Virtual Storage above the 31-bit bar. When the DBM1 address space starts up this Large Memory Object is allocated with a 128GB size. Communications take place between DDF and DBM1 using this area: But we’re not talking about data moves and reformatting anymore. So this should cut the CPU. (And it also removes the constraints I mentioned above.)

There are two key points here:

• This is Virtual and not necessarily Real memory.
• The 128GB object is not populated at creation time. So in all case (at least for now) 🙂 the Virtual usage is going to be an order of magnitude or two less than 128GB.

Virtual does drive Real usage, of course. But in this case the increase in Real memory requirement (and there’s bound to be some) is nothing like 128GB.

I should also point out there will be some Virtual storage savings – below the 2GB bar. That will be welcome to a number of customers I know. (And I may well blog about this soon.) But one caution:

I do not expect the need to manage thread numbers and thread footprints to go away, perhaps ever…

DB2 9 does not move the whole thread footprint above the bar. And threads still cost Real memory – though it would take many thousands to have an impact on memory capacity planning. You do do memory capacity planning, don’t you?

(Originally posted 2007-03-14.)

On Twitter I once followed Steve Wozniak – but it turned out not to be him. 😦

Now I’m following John Edwards (and it really does appear to be him). See his Twitter page. I say “it does appear to be him” because the twitterings seem to support that conclusion, plus there is a photograph of him (not that that’s strong evidence). (The ones for the supposed Steve Wozniak never gave credence – it was just a name.) I also see someone claiming to be Barack Obama though this time there are no twitterings (and no photograph).

So there are two issues that come out of it:

• How do you authenticate a voice when it claims to be someone – especially someone famous? And couldn’t someone sign up claiming to be eg Hillary Clinton and then post stuff damaging to her campaign?
• Is this cheap-to-mount personal campaigning style going to change campaigning?

The precedent for all this is the famous person’s blog. I follow but one of these, BTW: Brian May’s. (And he’s only just conceded that his “soapbox” is indeed a blog.) 🙂 But this is a little different as Twitter is much lighter weight: It’s easy to throw out a one-liner in Twitter. It’s rather harder to do that with a blog: People expect more of you.

(Originally posted 2007-02-24.)

I’m writing this in the back of a taxi – on my way to Heathrow. (A 3G card for my Thinkpad was waiting for me when I got home yesterday.)

My conclusion is that we live somewhere “sufficiently rural” as I’ve lost signal once. (That was between us and Henley.) Any more than that and I’d think we lived in the sticks. As it is to actually lose the signal at all is a reassurance that we don’t live anywhere urban(e). 🙂

And, no, I wouldn’t really mind if this “test drive” utterly failed: I only really need the card in places where the likelihood of a signal is strong anyway – such as airports and on trains.

(Originally posted 2007-02-23.)

Whichever it is, here’s my Twitter badge. Feel free to befriend. 🙂

(Originally posted 2007-02-18.)

Whatever one’s feelings about the definitiveness of Wikipedia a lot of people find themselves there, looking for information. Having twice anonymously edited articles – in one case to correct an error, in the other to add a minor snippet – I finally succumbed to the urge to get an ID. So my efforts aren’t quite so anonymous – and are therefore a bit more accountable.

I’m not going to go overboard with the literary style. And in any case with wikis the first writer is often not the one to beat it into shape. So you’ll see me contribute to pages on such subjects as z/OS and z9. (I just created the MIDAW page, for example.)

Come and join me! There’s much work to do on the mainframe-related pages.

(Originally posted 2007-02-08.)

Willie Favero is also blogging about this – and I stole the link from him…

Here’s the End of Service announcement for DB2 Version 7. It goes out of service on June 30, 2008.

I’ve just sat through four days of the T3 class for DB2 9 for z/OS – in Silicon Valley Lab. My “take home” message is that there’s lots of stuff in all the usual areas. It’s a truly exciting release.

Note: It’s “DB2 9” and not “DB2 Version 9” at this point.

So, with the End of Service announcement for Version 7, coupled with what I know of 9, Version 8 is a great place to be right now – in my opinion.

More on DB2 9 later.

(Originally posted 2007-02-08.)

See the z/OS Release 9 preview statement if you’re interested in z/OS.

There are lots of interesting Performance items previewed, as well as other line items.

It’s expected to become available in September 2007, following the current pattern of a new release each year (preview in the so-called Spring :-)and release in the Autumn) so expect lots more information on it later this year.

I do wonder how many customers will find today’s LPAR limit of 32 processors (CPs plus zIIPs plus zAAPs) to be a constraint. z/OS R.9 is expected to support 54 in total (CPs + zIIPs + zAAPs).

(Originally posted 2007-01-31.)

I suggested (in z/OS Release 8 Real Storage Manager SMF Record Changes) that I might talk about the changes to RSM in z/OS Release 8. As the release has been out now for about 4 months some of you might actually be on the brink of putting it into production. 🙂

Seriously, you probably are planning for the day when someone cuts over to Release 8.

RSM was largely rewritten – for a very good reason: The average LPAR has an increasing amount of memory. I typically see Production z/OS LPARs in the region of 10 to 20 GB, and I know they’re going to grow. (The largest machine I’ve seen, by the way, has 96GB on it.) As memory grows – usually faster than CPU – the cost of managing it increases:

• The CPU time increases.
• The time spent holding RSM and SRM locks increases.

So Release 8 sets about reducing both of those costs.

There’s another factor here: It is relatively rare to see an LPAR doing significant paging. Indeed most LPARs in my recent experience have gigabytes of unused memory. So, there’s less point micromanaging memory. Why agonise over which are the oldest pages in a system when you’re not going to have to throw any of them away?

The new algorithm looks very much like the old Expanded Storage algorithm… RSM keeps a cursor into the PFT. When the Available Frame Queue (AFQ) runs low, RSM needs to replenish it – to satisfy requests for memory (perhaps to back some new virtual storage page). Replenishment is undertaken by scanning the PFT, moving the cursor. Pages with the reference bit not set are deemed old and can be stolen (usually). Pages with the reference bit set have it reset, aging the page. So there is no UIC updating for pages. We sweep through memory looking for old pages (as opposed to new pages). Fixed frames (such as perhaps DB2 V8 buffer pool pages) do not participate in this.

This algorithm is much cheaper and allows LPARs to scale much better, memorywise.

RSM keeps track of how long it takes to scan the entire table. The longer it takes the less constrained memory is. And this is the new System UIC. Which is used to drive algorithms and eventually is surfaced as the Average System UIC (in RMF and SMF Type 71 records).

A question arises: Given that sometimes z/OS needs to know more than just the System UIC, how is this done? The answer is that memory is divided into (currently) 16 “Segments”. The timestamp at entry to the segment for the current sweep is compared to the timestamp for the previous sweep. This gives useful profiling information – and 16 data points.

I specifically asked the developers last summer “who stands to benefit the least from the rewrite?” One has to ask these questions – given that few algorithm changes are “all upside”. The answer was “memory-constrained systems”. So, if you have memory-constrained LPARs you might want to examine their storage allocations. If they’re Sysprog LPARs you mightn’t worry about it, of course. Depends on what you think of your sysprogs. 🙂