In-Depth
Mainframe Pros Question IBM’s Spending Initiative
Some mainframers think IBM’s $100 million could be better spent addressing training, licensing, and other long-standing Big-Iron pain points
Mainframe pros are a realistic bunch. It shouldn’t surprise anyone, then, that many see both good and bad in IBM Corp.’s announcement last week of a $100 million commitment to the mainframe’s future. Big Blue’s projected mainframe earmarks—which mostly concern better usability, easier manageability, and easier programmability—are without question important. Even so, many mainframe pros think such a large sum could be better spent addressing long-standing Big Iron pain points, such as training and licensing.
To recap, IBM last week announced plans to spend $100 million over the next five years to make its mainframe systems easier to use. The idea, officials say, is to make it less difficult for mainframe operators and systems programmers to maintain and code for Big Iron systems—in part by automating the development and deployment of mainframe applications. Big Blue’s $100 million push involves System z hardware and software specialists, as well as experts from IBM’s Tivoli, WebSphere, and Rational software groups.
“IBM will spend some money to create GUI interfaces for some mainframe functionalities. Hmm. There are existing mainframe interfaces to do the things that I heard they were 'improving'. They are not crude by any stretch of the imagination. However, they are not similar in appearance to a PC interface” says John Walker, an SMP/E operator with a large manufacturing firm based in the midwest.
Even so, says mainframe technologist Steve Comstock, IBM’s vision should be applauded—even if its execution often leaves much to be desired. After all, Comstock points out, winning back the hearts and minds of long-time IT managers—and capturing the attention of new IT pros entering the market for the first time—is a laudable goal. “[A] good PR campaign [such as last week’s effort] is essential, [but] I am skeptical the new campaign will be spot on, based on IBM's recent campaigns.” Comstock comprises one half of a two-man support team in a small mainframe shop.
One concern, Walker and other mainframe pros say, is that IBM doesn’t so much intend to simplify the mainframe UI—or user experience—as to retool it for a whole new class of user. “The issue really is not that there is a need to simplify the interfaces. They are already simple and pretty obvious. I believe the issue is … 'non-traditional users.' They are saying they don't like an interface that doesn't look exactly like a PC interface. Okay, it doesn't look like a PC interface. IBM is dealing with a complaint in a customer-oriented way. I don't see any problem in that. However, it does appear to be unnecessary work.”
What’s wrong with that? Nothing, on the face of it, but Walker argues that the salient point is that much of this money could be better spent in other ways—such as improving DB2 performance and value. In this respect, Walker acknowledges, IBM’s new zSeries Integrated Information Processor (zIIP) is a good start.
“zIIP engines? Great idea. I approve of it, and our company has one or two already. Why did we get a zIIP engine? Simple. DB2 sucks. As a former computer operator who watched the CPU's closely when DB2 started being used extensively for the first time, I know what DB2 does to a mainframe. DB2 is inefficient in terms of its I/O, and it consumes CPU like a hog at the trough.”
In other words, Walker argues, zIIP is a practical concession on IBM’s part to poor Big-Iron DB2 performance. “I watched as entire CPU's were consumed by runaway SQL's that should not have been implemented. Yes, some of those issues have been retroactively dealt with in the last decade. Still, the underlying issue is this: DB2 is an I/O method written on top of another I/O method [i.e., VSAM] which implements other code [SQL]. When any application has too many layers of code built up, one layer over another over another, there’s trouble” he points out.
Nor is this just kvetching, stresses Walker, who’s a realist in most respects. There will always be unnecessary CPU use, he says. “It is unavoidable. I know this is unavoidable because industry has made a commitment to use DB2. Still, all DB2 is is a methodology to correlate information in a convenient way. The truest solution to fix DB2 is not saying, 'Yeah, it sucks, so we'll build special CPU's that deal better with its inefficiencies'. That's what zIIP engines do. The truest solution is to not use DB2, but instead create another way of correlating data which is more efficient than DB2. [But that] won't happen.”
Licensing, Training Issues
Comstock, for his part, would like to see IBM concentrate on other, even more obvious mainframe pain points—such as licensing. “Fix the pricing: [make it] lower and simpler. It's a competitive world out there, and IBM simply can't afford to put its head in the sand,” he argues.
Nor is that all; Comstock is just getting started. Take mainframe training, which --when it comes to hand’s on, emulated, or remote access to Big Iron hardware—is still a prohibitively expensive proposition, at least for many frustrated would-be trainees. This is an old lament, as it turns out—and it’s further proof, some mainframe pros say, that IBM continues to ignore more vexing—or potentially more costly—problems even as it pushes PR-friendly efforts.
“[IBM should] allow more access—either [create] free or very-low-cost entry points for the hobbyist or small software developer. This would include allowing such an audience to legally run z/OS under Hercules on a laptop,” Comstock maintains.
To the extent that IBM’s new mainframe push helps produce skilled mainframe programmers and administrators, that’s a good thing, says Walker. But the danger, he alleges, is that Big Blue’s efforts will emphasize competency at the expense of skill. In other words, while IBM’s $100 million push could produce mainframe interfaces or methods that are more familiar (at least from the perspective of non-traditional personnel), it might also do little to foster the emergence of a skilled operator and programmer class to complement (and eventually replace) the mainframe wizards of today.
If that happens, Walker says, companies will have all the incentive in the world to look elsewhere—in many cases, far offshore. He says that’s already the situation today. “Management increasingly relies upon semi-trained programming staff [who are] good at communicating, fair at programming, [but] it has become more and more obvious that there is a need for skilled programmers to get the work done,” Walker points out. “If we consistently ‘get our skilled people over there,’ we will increasingly cause our potential pool of skilled labor to dry up.”
Related Article:
An Rx for Mainframe Viability