|HOME||PUBLIC LIBRARY||ANOTHER PERSPECTIVE||INFOPERSPECTIVES||CONTACT|
"Six months ago, I cut back Dobbin's oats by a third," Farmer Jones explained. "I used sawdust to bulk up his feed. Then three months ago I got him used to eating two-thirds sawdust. I was training him to live on pure sawdust when he up and died. Now I'm going to have to start all over." IBM generally advises VSE shops to use zLinux for new applications and wants them to stop asking when it will let them harness 64-bit mainframe technology for their legacy workloads. It's no wonder VSE users feel like a dying breed.
IBM has been trying go get VSE users to move to alternatives for ages. In the past, IBM tried to upgrade them to MVS. Today, IBM makes it clear that the proprietary operating system it wants mainframe users to run is z/OS. But the VSE crowd has rejected Big Blue's message, for a number of pretty good reasons. VSE and the software it supports have always been less expensive to license than MVS, OS/390, or z/OS alternatives. This has been the case since the mid-1960s, when IBM offered DOS/360 to users of smaller System/360 mainframes as an alternative to its flagship operating system, OS/360. z/VSE is a descendant of DOS/360, while z/OS is in the family that began with OS/360. IBM's third proprietary environment for the mainframe, z/VM, is not in practice much of a production system at all. These days it is essentially a virtualization product that at various times and in prior incarnations has helped IBM deliver multiprogramming, interactivity, and partitioning; its technology is also the basis of IBM's mainframe management microcode.
Over the years there have been times when it looked like IBM threatened to freeze VSE, putting users under pressure to migrate to MVS. There are three major events in mainframe history that have imperiled VSE users. The first came with the introduction of XA architecture in the early 1980s. At the time, IBM mainframes were 24-bit machines. XA was IBM's first step toward 31-bit architecture, and while Big Blue announced versions of MVS to take advantage of XA, it told VSE users they would have to keep running in the pre-XA mode, which would continue to get support.
IBM completed the development of its 31-bit architecture in the next stage of its mainframe evolution, ESA, in the mid-1980s. By that time IBM was faced with a pretty stark choice: offer an updated VSE for ESA machines or lose control of its base. This was a serious issue. Third party lessors were very strong, Amdahl and particularly Hitachi had big bases to protect, and a number of ISVs serving the VSE base felt they had to come up with something for their nervous customers. All three of these groups had an interest in keeping VSE users happy and, unlike IBM, they had a far greater interest in enabling their customers to keep using older hardware and software than did Big Blue. The upshot was a lot of support for third party software that helped smaller mainframe shops extend the lives of their aging systems. IBM was overwhelmed and in 1990 it blinked, producing VSE/ESA.
The third big threat to the VSE base is now reaching a crisis point. IBM has killed off its 31-bit mainframes and brought out technology that enables its 64-bit systems to be scaled down to match the requirements of smaller shops, in performance if not always in price. Yet another 64-bit generation is in the wings and after that IBM will probably be moving to Power6-based mainframes, opening the door to architectural possibilities beyond those provided by the current z architecture.
Environments, language processors, database engines, and other software sold to the big shops that use z/OS are pretty expensive compared to software used by VSE shops. Migration from VSE to OS is expensive. Ongoing support can be more difficult, not so much for applications once they are moved but for systems work, because tuning the more complex z/OS can be pretty difficult.
IBM could, perhaps, find a way to support legacy VSE applications under z/OS, drastically reducing migration costs. IBM could also make it easier for smaller shops to optimize their workloads with the help of tuning tools or firmware enhancement. But it's hard to see how IBM could find a way to cut the total cost of a z/OS system for small users like the ones in the VSE base without also slashing prices for big users.
For VSE shops, the alternatives no longer include third party software that extends the life of legacy applications, some of which have never even been moved from 24-bit to 31-bit software technology. The only compatible alternative is the Flex-ES emulator, which has not yet been blessed by IBM for commercial users with 64-bit software. (Developers are allowed to use Flex to emulate 64-bit mainframe environments.) The upshot is that VSE users who feel they can no longer go forward have to consider pulling the plug on their mainframes and moving to other hardware platforms. Users who just want to stand still (and use other platforms for new applications) can still get used machines, independent support, and third-party maintenance. Users who are downsizing and can't find smaller mainframes can buy capacity from services companies. But alternatives for dormant or discouraged shops are not the issue. What IBM has to address is the situation of VSE users who really want to make progress but don't want to give up their familiar computing environment.
When IBM lost mainframe customers to PCM manufacturers or lost sales to third party lessors it never lost the possibility of winning them back. After all, whether they paid IBM or Hiteachi or Comdisco for their mainframes, they were still using IBM architecture platforms. But users who move from VSE to a Linux, Unix, Windows, or OS/400 environment are never going to come back.
IBM is obviously aware of this. If it decides that it will offer a VSE with 64-bit extensions and features to reassure edgy users and keep them from leaving, it will have to say something pretty soon. There's no point in closing the door after Dobbin has died.
— Hesh Wiener April 2006