(Originally posted 2016-07-02.)
This post is occasioned by a number of things coming together, the most recent of which is reviewing a very nice upcoming RedPaper.
The gist is this: You’re responsible for managing Performance, Capacity and (to some extent) mainframe costs. But you can’t rely on anybody to tell you anything.
A bit pessimistic, perhaps a little misanthropic. But still something I’m sure a lot of you can relate to.
There are two major exemplars that cause me to write this post:
There, I’ve got two buzzwords into a post. 🙂
But let me take each in turn.
My main interest in mobile work is the potential for customers to take advantage of Mobile Workload Pricing (MWP).
Entirely correctly, people are exercised by the need to “Tag and Track”:
- Tag means labelling the work as Mobile, whichever application architecture you choose.
- Track means using the tagging to report the Mobile CPU.
I would add a third (or rather a zeroeth 🙂 ) one: Identification. And herein lies the problem…
Since the announcement of MWP I’ve been taking soundings with customer friends: I’ve asked them “If someone introduced new mobile workload to your systems would they tell you?”
Maybe I’m being humoured but their take has been “not necessarily”. I’m inclined to believe them.
The implication of any non-reporting is clear: Opportunities to exploit MWP might be missed. And one implication of that would be z/OS is unnecessarily less competitive than it might be. I certainly don’t want that.
One thing to note is I don’t think you can assume you’d detect new mobile work, nor to discern its eligibility for MWP in any automated fashion. But I hope you would detect new work showing up.
Cloud presents a different problem:
On z/OS the usual approach to cloud deployment is not to create new LPARs; Rather it’s to deploy new subsystem instances, such as MQ queue managers, DB2 subsystems and CICS regions.
While I’d never advocate making things unnecessarily difficult, making them very easy might have an unintended consequence: Not enough attention to the implications of deployment.
So, for example, the memory footprint of a new DB2 subsystem, another MQ queue manager, and a bunch of CICS regions could be significant. Yes, modern machines tend to have tons of memory but it still needs to be provisioned and managed.
I haven’t done Security for over 25 years but I would suspect there’d be companion concerns there, too.
The good news here, though, is you can detect new containers and their interconnectedness. I’ve written about the SMF 30 Usage Data Section extensively. (If you haven’t picked up on this read this 2012 post of mine.
Mobile and Cloud Have Much In Common
Both these cases are examples where work can show up on your beloved z/OS systems with no warning; You’re expected to handle it optimally.
It’s not often I write about such an “up-market” topic as Governance  but I think this is what is called for.
Your processes for onboarding work are what’s important here:
- It needs to be the culture that new work arriving needs some sort of review.
- For Mobile business application owners need to understand the opportunity for cost savings if they enable you to Identify, Tag and Track work.
- For cloud it shouldn’t be the case that the ease of deployment leads to unannounced “new arrivals”.
- Detection and tracking – to the extent possible – is key.
- Architecture remains important: A hodge-podge of new applications, without considering architecture, is not what’s really wanted.
- The above sound like “policing”. More positively, Performance Tuning and proper Resource Provisioning can make a big difference to how well the business owners view the successive of the deployment.
I don’t know anymore if my readership is confined to (bemused) Performance People. I would hope it would now include architects. In any case y’all are key to successfully managing cloud and mobile workloads on z/OS.
Or, maybe, into existing ones. But the most prevalent case is whole address spaces. ↩
Or is it oodles? 🙂 ↩
The previous time was with Jan van Cappelle in REDP–4816–00 “Approaches to Optimize Batch Processing on z/OS” from 2012. ↩
Because I go off on tangents like this one. 🙂 ↩