A Minor Fact About Lock Structures
MartinPacker 11000094DH Visits (8006)
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:
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.