A Minor Fact About Lock Structures

(Originally posted 2008-06-04.)

Sometimes reading the SMF manual buys you less than you thought. I had completely ignored a nice little field – and the code I inherited to analyse SMF 74 Subtype 4 Coupling Facility data ignored it as well.

R744SLEC in the Request Data Section for a structure is described by the text “Lock structure only: lock table entry characteristic”. Can you guess what it is? 🙂 If I told you it was a one byte integer would that help?

If I had bolded the word “characteristic” would that have helped?

Probably only if you knew something about floating point numbers. I confess to knowing little about them other than the fact there is a “characteristic” and a “mantissa”. One’s the “power of n” thing, and the other’s whatever you multiply it by. But which is which? Anyhow…

So my first guess is that this field is the number of bytes in a lock table entry – plus one. I see values of 1 and 3 in it. So 2-byte entries and 4-byte entries. Right? Wrong! …

My friend “SuperMario” 🙂 points out to me that I’m looking at a GRS Star ISGLOCK) structure when I see the “3” and further that GRS Star always uses 8-byte lock table entries, no matter how few members (systems) connect to it.

The penny drops…

23 is 8, right?

So the “characteristic” is really in this case the power of 2 that turns into the number of bytes in each lock table entry. So “3” means 8 bytes (as I just said) and “1” would mean 2 bytes (which figures for the plexes I see it for, being relatively small). So there’s that word “characteristic” again, and the field description (though terse) seems to make sense. 🙂

Now, why’s this important?

For two reasons:

  • The installation has a choice of how many bytes to make each lock table entry, depending on the maximum number of lock table entries they want to cater for – without a rebuild. So, too wide a lock table entry and you waste lock structure space – potentially massively. Too narrow and you can’t connect all the systems (or e.g. DB2 members) you want to. Usually not a difficult trade off. But now I can wade into the discussion in a customer with evidence. 🙂
  • The almost-neighbouring field R744SLTL gives the maximum number of lock table entries. Multiply the two together and you get the size of the lock table portion of the lock structure. The remainder – R744SSIZ minus the lock table entry size – is for record portion of the lock structure. There are various ways to make a hash (pun intended) of this. Which I won’t bore you with here. The point is you can do this calculation, armed with what the characteristic is.

Well, I thought this was a step forward in our understanding of how lock structures were actually allocated.

On the morrow (otherwise known as “presently”) I’ll write this up in the Redbook.

I’m taking the slightly unusual stance of assuming the readership can get the SMF manual out and follow along. Or at least wave around an SMF field name like it’s their “new best friend”. 🙂 Actually I’m using field names for clarity. There are – as I point out in the Redbook – at least 4 valid size fields for a structure. It’d be nice to be clear which one we’re talking about.

So we’re having fun in Poughkeepsie, going deep into the instrumentation. And we’re having nice discussions about what all the fields mean (and what they don’t mean). Here’s an example of what they don’t mean…

Field R744SSTA sounds like it ought to mean the number of Sync requests converted to Async. But in fact it’s almost always zero, despite the z/OS R.2 Dynamic Request Conversion – which we know goes on all the time. How do we know? I’m not sure really, except that in many situations we see plenty of Async requests where the exploiter is highly likely to have requested Sync. So this field turns out not to be the R.2 algorithm “in play”. It’s the older, possibly best dubbed “Static Conversion” algorithm. So, such things could easily trip you up. Or maybe it’s just me that stands to be tripped up. 🙂

Like I say, we’re having fun here in Poughkeepsie. 🙂 And if you happen to think this sort of thing is fun a residency could be right for you. Now, you might think as a customer (or other non-IBMer) you don’t have the possibility of being selected. In fact the “wall of fame” has photos of quite a few non-IBMers on it. No, I don’t know how it works with non-IBMer nominations. But it seems to be a non-zero-yield process.

Published by Martin Packer

I'm a mainframe performance guy and have been for the past 35 years. But I play with lots of other technologies as well.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: