Most of the time change can be so gradual that we don’t notice the creep until the problem is critical. In the mainframe world we submit batch jobs for this and that all day long, but over night we have windows of time dedicated to large specific chunks of work. There’s a backup/archive window, a synchronization window, a nightly processing window, and the good old online-is-down window. The trouble comes when one window becomes tight and then starts to affect the other one processing. For instance: If your nightly batch window has a problem or runs over, then those offshore folks won’t be able to get online and work.
Thankfully, many of the corporations I have the pleasure of working with are doing well, and they are experiencing growing pains. One such pain is frequent mainframe upgrades. In the past, upgrades occurred years apart. Now they are months apart. An upgrade on the mainframe is a significant cost and one that isn’t always budgeted. When your company grows, so do the jobs you submit. Most times a customer doesn’t realize that if there was a way to make jobs run faster they’d not only get time back and stop the windows from shrinking, but they could slow down that impending upgrade price.
IBM provides us with all the mainframe machine resources we need, but it’s up to us to make the best use of them. You might not realize this, but you’ve got two choices:
Yes, we can instantly adjust all those resources on the fly automatically to improve the I/O throughput of your jobs.
Think about that – you’d get time back. How much is that worth? What could you do with more time? Would your increased productivity allow you to get more done, and you’d generate more revenue? You betcha! I’ve seen customer jobs cut in half and the customers fell out of their chairs with delight.
Job Optimization is a solution of pure cost savings, cost avoidance, and increased productivity. That’s got to fit into every CIO’s action plan. It may be time to shrink your mainframe windows.
|
(0) Comments Click here to read/write comments
|
 
|
Most organizations figured out a long time ago that instilling some level of governance and control over application source code (your business applications running on the mainframe) was a very good idea. This governance:
Yet as sound as this is, I’m amazed at how the other half of the mainframe is open and unprotected. By and large, most firms don’t have any change governance in place against the system software (the software that’s running your mainframe). This means that your system programmers can grab any object or member, make a change and throw it into production.
When I see this in a mainframe shop, I say: “Congratulations, you’ve got half of your world protected!” At first they are a bit confused because they are proud of their change management system, until they realize that it’s only protecting the application code and not the system software. This is the stuff that drives auditors crazy and, if it were known, would keep the CIO up at night.
For the most part, there are fewer system programmers than application programmers in organizations, but their work is complex and crucial to operations. And when questioned about change governance against system software objects, most firms will admit that this is an unprotected area currently being controlled by a bunch of good people being very careful. The reality is that allowing your mainframe system software to be vulnerable is a large business liability that can affect your continuity of operations. Think about it this way: it’s impossible to run your mainframe billing application if the mainframe is not working properly.
It only makes sense — protect your mainframe system software… all of it!
Is this your situation? Does your Auditor or CIO know this? Give me your thoughts in a comment below.
|
RSS Feed
