So you have all your source code under change control. If it’s under control of ChangeMan ZMF you are in the best hands possible.
But what about all those other datasets? How do you control the changes to the SYS1.PARMLIB? How would you know if an authorized application updated SYS1.LINKLIB? How do you keep changes to SYS1.PROCLIB in step on every image?
It’s not only SYS1.** but what about the configuration datasets for CICS, IMS, DB2 and for Websphere? There are thousands of datasets in our infrastructure that are not under any form of change control other than through the security access controls of RACF, ACF2 or Top Secret.
Of course, secure access control is usually enough but errors do occur and they can go unnoticed for hours, even days before their effects are discovered. This is why you need to put your system files under change control too; but a new kind of change control that meets the dynamic needs of systems programmers and the risk parameters of the business continuity team.
ChangeMan SSM provides real-time tracking of system datasets. The systems programmers choose which ones and report changes as they occur. Changes are noted and stored away in a dataset. In the future, those changes can be reviewed and, if needed, can be restored to their original state through a very simple online interface. Of course, the changes can be propagated to other systems too if they are needed elsewhere, thus making multi-system changes easy.
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.
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.