You don’t hear much about System z software governance. We do, however, hear a lot when software fails, including mainframe software. Jeff Papows, CEO of WebLayers, a software governance vendor, wrote a recent book on the subject, Glitch: the Hidden Impact of Faulty Software (Prentice Hall, 2011).
One such software glitch caused a bank to charge a customer $23,148,855,308,184,500 for a pack of cigarettes he charged on his debit card. Spelled out in words, that’s twenty-three quadrillion, one hundred forty-eight trillion, eight hundred fifty-five billion, three hundred eight million, one hundred eighty-four thousand, and five hundred dollars. Plus the bank charged a $15 overdraft fee; at least that part of the software was working right. Papows doesn’t say, but given the predominance of the System z in the banking industry, it’s a reasonable bet it was a System z application that screwed up.
OK, this was extreme, but we all know of mistakes on financial statements, airline delays, lost parcels, missed payroll checks. One of the most ominous of the recent software glitches was the loss of power to the controllers at a U.S. missile launch command, which left a large chunk of our nation’s defenses inoperable for almost an hour.
Mainframe software governance is the process that helps organizations avoid these kinds of glitches. At many mainframe shops, however, testing and code review are about the closest they come to software governance. Those are important for catching coding errors and software bugs, but don’t do the whole job.
Software governance operates at a higher level where it can flag and avoid a wider range of problems. Software governance, policy-driven and best when automated, monitors the software process through all phases and focuses on conformance to policies, best practices, risk reduction and efficiency. Testing and QA, by the way, also should be subject to policy-based software governance.
With a large proportion of the world’s code running on mainframes and the System z and zEnterprise moving deeper into cloud computing and capturing new workloads, mainframe software governance is more important than ever. The payoff will come in three areas: 1) better quality code that conforms to best practices, 2) lower cost by enforcing efficient coding practices, and 3) reduced risk identifying deviation from policy early in the process. When it is policy-based and automated, software governance also has the ability to capture critical mainframe expertise and transfer it to the next generation of mainframe programmers.
Here are three policies pulled from WebLayers’ zCenter mainframe software governance product, which comes with a library of 1000 such policies. They aim to speed performance, reduce costs, or transfer mainframe expertise:
Policy: Do not use USAGE DISPLAY data items for computations. Avoid the use of COMP-5 vs. COMP when the total field length is greater than 4
Results: Computations will be up to 70% faster if Usage Display is not used in computations; Comp-5 is twice as slow as COMP when field length is greater than 4 digits
Reduced MIPS consumption
Policy: Use Compute when using COMP-5 fields
Results: CPU savings of up to 400%; Use of the COMPUTE verb is easier to maintain
Passing on mainframe experience
Policy: Use indexes instead of subscripts for addressing table entries
Results: Using indexes to address a table is more efficient than using subscripts; Savings of up to 5-50% depending on the usage type of a Subscript
You can find more examples in Independent Assessment’s complete white paper on the payoff from mainframe software governance.
DancingDinosaur does not usually go into the nitty gritty of mainframe coding. However, it is hoped that a peek at governance policies will inspire you to look closer at the issue of software governance on the System z and the payoff it can provide.