Since the advent of Linux on the mainframe, there’s been a glaring gap in IBM’s ability to support mainframe workloads—the lack of support for Windows. Until recently, this gap effectively didn’t matter in the real world. In a world of throw-away, scale-out Wintel servers, little concern about energy, and technical barriers to moving many Linux applications to the mainframe (e.g., lack of common middleware available for Linux on both Systems p and z), there’s been little pressure to move from Windows to scale-up platforms such as the mainframe.

However, IBM now offers comprehensive common middleware across the mainframe and its other platforms, and today, compelling reasons to want to move Windows workloads to the mainframe include:

  • The mainframe’s superior energy profile
  • The ability of the mainframe to deliver long-term costs per application well below Wintel scale-out in cases where the enterprise can move 20 or more Windows applications to a single mainframe.

This lower Total Cost of Ownership (TCO) fits well with an economy where decreases in a business’s customer spending heighten the need for lower IT spending. IT cost growth paths are now 10 to 20 percent below their past norms.

Opportunity and Dilemma

Cloud computing presents mainframe users with an opportunity and a dilemma. Cloud computing demands that enterprise applications first be carved up into groups as Web services, then virtualized so the software can be moved to an internal or external cloud. The aim is to cut large-scale costs of both administration and hardware; the mainframe excels at both. However, as long as the mainframe can’t support a large body of enterprise Windows software, external cloud vendors or internal cloud creators must decide between a partial solution that replicates the existing Wintel/mainframe split and doesn’t save much on costs or a move toward Wintel platforms that will increase long-term costs.

It’s now possible to talk about the mainframe handling most applications inside or outside a cloud, and to envision migrating most Windows software to the mainframe in the lifetime of an IT administrator. Let’s summarize the new possibilities for moving workloads and how they overcome the technical challenges to migration.

Windows-Mainframe Migration Tools

To understand the potential of the new Windows workload-to-mainframe tools, it helps to understand the technical difficulties they seek to overcome—difficulties that have, according to IBM, previously prevented the System z from giving users a reasonable way to move Windows workloads to the mainframe.

The traditional way of porting a workload from one environment to another is to simply copy the operating system—in this case, Windows. However, the mainframe has a unique Windows portation problem. The IBM z10 supports both Linux and the proprietary z/OS—the operating system runs directly on the hardware—“natively.” However, it can’t support “native” Windows. More specifically, native Windows can’t use z/VM, so you would have one Windows application instance taking up the entire mainframe—not a cost-effective solution!

Until recently, to move applications from Windows platforms to the mainframe (or, more typically, vice versa), users would go to a porting company to separately port each application. Some applications are easier than others to port from z/OS to Windows: those written in COBOL, in particular, and those depending on CICS or DB2 also are fairly straightforward. By the same logic, those Windows applications that mainly depend on DB2 or IBM middleware allow fairly easy porting from Windows to the mainframe. In the typical case, however, a company may seek to port hundreds of applications between Windows platforms and the mainframe, and the task can take a year at minimum—often far longer.

2 Pages