When Reality Bytes

(Originally posted 2018-05-12.)

In my “How To Be A Better Performance Specialist” presentation I have a bullet point that says ‘there’s no value in being “The Man Who Knew Too Little”’.

Well, it astonishes me how often I am the man who knew too little. 🙂 I guess we keep on learning OR ELSE.¹

In the spirit of “I’ve become sensitised to something so you should, too” I’ll confess that I live in a comfortable bubble where ignorance of some realities is bliss. This post is about that, but also a wider point.

I don’t know if you’ve ever seen a real mainframe, preferably with its clothes off 🙂 (or doors open at least). If you haven’t, I really think you should. We talk about machines in an idealised way: “This many engines” or “that much memory”. But it’s nice to actually see one – and not just the hollowed out ones on display at conferences or IBM labs.

Recently I enjoyed some time in the Singapore Plant (which I will call “84” – as that’s the only manifestation of it in the data). I was shown a ZR1 – which is indeed narrow², being in a 19” rack. I also got to see – and not for the first time – a z13 and also a z14. I can now tell one from the other, without seeing the badge.

By the way, there is a “16U” space for you to potentially put your own stuff in the ZR1. It’s time us mainframers learnt a bit about (the aforementioned) 19” rack terminology. “16U” is 16 standard units high, by the way.

But let me come to the point.

Lesson 1: Physical Hardware Considerations Matter

We’ve been talking to a customer about coupling facility ICA-SR links. We think they should ideally have double the number. But two bites of, ahem “reality bites”:

1. They are on zEC12 hardware now and doubling the number of links can’t be done.
2. When they get to z14 hardware there are drawer-level limits to the numbers of links.³

Figuring out which device type a machine is from SMF is trivial. ⁴ What isn’t trivial is working out how many drawers. You would have to do it from the model. At last, with z14 it’s straightforward:

• If ZR1 it’s 1 drawer.
• If M01, M02, M03, M04, it’s 2, 3, 4 drawers, respectively.
• If M05 it’s also 4 drawers. But these are different drawers.

And we have considerations for upgrades. So, M01, M02, M03, M04 can’t be upgraded to M05.

We know, based on the model number, the limit of characterisable or “customer” PUs.

ZR1 poses an additional difficulty: There are four different feature codes for the maximum number of customer PUs: 4, 12, 24, 30. So it’s not good just saying “it’s a ZR1”.

Fortunately there is a new field in SMF 70, introduced by APAR OA54914. It is SMF70MaxPU, which is how many processor cores are physically available for this particular machine.⁵

Another example of “hardware considerations matter” is the upgradability of processors. For example, from December 31, 2016 you couldn’t order upgrades to zEC12 that required physical hardware.

Lesson 2: How Something Actually Behaves Matters

Some people would consider I was in Marketing. While I don’t dissent from that, I’d like to think I was quite technical⁶. One of the things you get “in the field” is lots of marketing material, much of it reasonably technical, on product capabilities. While we can readily absorb quite a lot of this, it doesn’t really come to life until you see it in action. In a real customer situation.

I’m not sure this is a good example of it, but it’s one I came across recently: Mobile Workload Pricing (MWP) is, in principle, a nice software pricing scheme to reduce the cost of Mobile work on z/OS. You agree with IBM how Mobile work will be measured and this is factored into your software bill.

That last sentence is incredibly high level – and that is deliberate. It’s actually pretty close to how some people understand MWP. But to really understand what it can do for you takes a much deeper understanding.

In particular, what counts is how big the Mobile work is at the Rolling 4 Hour Average CPU peak. In a recent case this was in the middle of their nightly batch. This is an environment that serves essentially a single time zone. Unsurprisingly, there isn’t a lot of Mobile work at that time of day, so the benefit of Mobile is relatively small.

So this is an example of how something actually behaves mattering. Fortunately we have instrumentation that speaks to this.

By the way, Mobile is an example of something where a financial benefit might distort the architecture: Do you really want separate Mobile CICS or IMS regions? Fortunately, WLM APAR OA47042 and corresponding CICS TS 5.3 support made Mobile classification of transactions much easier. But many installations implemented Mobile with separate regions. A few went with the more intensive method of measuring individual transactions. I don’t know, by the way, of customers using separate Mobile LPARs – which remains a possibility.

The reason for that last paragraph is there’s another point: Architecture matters – and especially how it behaves.

Minor factoid: The XML element in the WLM policy that governs this new Mobile capability is Reporting Attribute. I know this because the customer kindly sent their WLM policy to me in XML format – and I coded my parser accordingly.

How Hard Are These Lessons To Learn?

I always feel it’s lame to end a piece – whether a presentation or a blog post or anything else – with the words “In Conclusion” so I won’t.

I’ll just reflect where I am with it:

I’ve said I’m more a software person than a hardware one – but that’s because I can readily make software do my bidding. I’m increasingly sensitised to hardware configuration aspects but there’s a lot to learn there and not all of it is relevant. Further, I like machines to be self documenting – and the data model is not exactly complete. But APAR OA54914 takes us a little further.

“How stuff actually behaves” is one where you really have to see data. In the case of Mobile I’d say that data is a combination of what the terms and conditions say, in particular the Mobile contract exhibit and the scheme itself, plus performance data.

In both cases this is really about experience. More than 30 years in, I’m still learning at a very rapid rate through formal materials and, equally importantly, customer experience. I guess this is my version of On Practice. And I guess learning is the real point. Which is handy, as we’re just about to kick off System Z Technical University in London – and then I go to do the other thing with a customer workshop.

And I count myself as very lucky to know so many diverse customers around the world.