Open source mainframe software: Two perspectives
Would open source mainframe software allow systems programmers to make their systems work better and fix the mainframe pricing problem? Or would it open up shops to self-inflicted problems for IBM to fix?
The column I wrote a couple of months ago about why IBM should make the mainframe open source raised different reactions with opposite views.
One side was best summarized by an old system programmer who remembered the days when IBM shipped the source code along with the system. He noted how the source code made debugging much easier.
 |
||||
|
|
|||
|
||||
It was also very educational for the curious who spent a few minutes looking through the code to learn how the system worked. Finally, and only occasionally, a wise systems programmer could carefully modify the system to make things work a little better for his shop.
A retired IBM service representative took the opposite view. He remembered long days fixing self-inflicted problems for users who made ill-advised customizations to the system. He also did his share of helping systems programmers retrofit modifications to new releases. Lastly, there were plaintive cries from users who couldn't upgrade to new releases because there were too many customizations that would not fit into the new software.
IBM sought to ameliorate the situation with the reviled Object Code Only (OCO) policy. However, in exchange for yanking the source, IBM added many more exit points with structured, well-documented interfaces. In addition to the exits, IBM provided programming interfaces for changing and gathering system information without resorting to actually touching control blocks. These changes resulted in more stability and gave users a smoother migration path as long as they stuck to the published interfaces.
IBM gained some maneuverability from these changes as well. Since customers no longer had to touch control blocks, IBM could move and change them more easily. IBM could also add new features and modify old ones while worrying less about instantly crippling a customer's mission-critical application.
As is true for all life, this was not a universal blessing. Customers who once tailored the system to their own needs now had to make suggestions to marketing or submit "requirements" through user groups such as Share. Then, if it deemed a request worthy, IBM would approve of the change and include it in its plans, sometimes years into the future. Regardless of the ever-increasing number of exits, it often seemed that the one you needed wasn't there.
Independent software vendors (ISVs) had a few problems adjusting to the new circumstances. Their ability to sink hooks into the system became problematic and made them more dependent on IBM.
Lastly, the skill level of systems programmers began to drop. Technical support couldn't know in detail how IBM implemented a function or even how it worked. What's worse, as an unintended consequence, systems programmers became even more dependent on IBM support for debugging system and application problems as well as performance and configuration.
I think mainframe open source software might avoid the pitfalls outlined in the second viewpoint.
The benefits of an open source mainframe
In the open source world, a systems programmers' skill level will rise and her or she will become more like a technician and less like a janitor. He will be able to fix more problems on his own by referencing the system code. Knowing more about how the system turns will also enable him to make more intelligent configuration and tuning changes. Finally, given the fact that the customers know their requirements better than anyone else, a systems programmer will be able to add new features more quickly, efficiently and effectively.
Open source may cause an explosion of ISV development, as system interfaces will be much easier to find and maintain. However, to prevent total anarchy, ISVs will have to get together to make some sense of where to sink their hooks. They may even work with the open source community to come up with their own structured interfaces.
IBM will see some benefits as well. Due to the complexity of the code, IBM will be the provider of choice for many years. As a provider, IBM can rake in the money for support while reaping the rewards of customer-driven innovation. Most importantly, making mainframe software competitive and attractive will translate into more hardware sales as well.
Of course, this all depends on IBM letting go of the crown jewels. But, as any regular reader probably knows, I don't think the present mainframe software pricing model is sustainable. In the next decade or so we're going to find out if it changes or if the mainframe dies on the vine. For me, open source is one path to the light.
ABOUT THE AUTHOR: For 24 years, Robert Crawford has worked off and on as a CICS systems programmer. He is experienced in debugging and tuning applications and has written in COBOL, Assembler and C++ using VSAM, DLI and DB2.
What did you think of this feature? Write to SearchDataCenter.com's Matt Stansberry about your data center concerns at [email protected].
