Richmond says Sabre expects to transition its international and multiroute domestic services before the end of the year. The step will allow the company to retire one of its three TPF datacenters, each of which contains about eight mainframes. During the next 18 months, Richmond expects to migrate Sabre’s core passenger itinerary service to the distributed system as well, eliminating a second TPF datacenter. That will leave only the master transaction database. Richmond thinks he may need to stick with IBM TPF for that one, at least for a while, as HP isn’t yet certain it can deliver the TPF-level fault-tolerance that that database needs.
All told, this ambitious, multiyear migration effort costs “a significant percentage” of Sabre’s annual $150 million IT budget, but Richmond says it’s well worth it. He says costs are already less than half of what they had been, mostly due to savings in per-transaction charges for the TPF facility.
Small Shops the Clearest Winners
The DCCA and Sabre Holdings examples show the longer-term promise of mainframe migration for large IT infrastructures. But according to Forrester’s Phil Murphy, smaller shops -- especially those that use their mainframes primarily as application servers -- can make the best case for migration today. These small-scale mainframe environments are typically less complex than one like Sabre’s, for example, yet they still cost significantly more than equivalent distributed systems.
Vestcom, a company that prints and distributes financial statements on behalf of banks and brokerages, is a prime example. A quarter of its IT budget went to pay for hosted services on an IBM System/370 mainframe running VMS, which provided about 150 MIPS of computing power.
Vestcom used the mainframe to download huge quantities of data, apply various formatting and calculation rules, then create and print the statements. But as revenues plummeted following the dot-com crash and a series of accounting scandals, the company needed to lower costs quickly. Vestcom CIO Joe Mislinski says the mainframe was an easy target.
Mislinski hired Micro Focus to port Vestcom’s Cobol code to a quad-processor x86 server. Sticking with Cobol as its application language allowed Vestcom to reduce the number of variables in the transition, but some things just didn’t translate.
Case in point: The mainframe could handle very large jobs and recover at any point in case of printer failure. In the new environment, however, tasks were distributed as several parallel sub-jobs, each going to independent printers. If a printer failed, there was no master job image that the software could use to recover from the interruption point.
“But none of this was insurmountable,” Mislinski says. Vestcom ended up creating its own management tools to track the status of each sub-job on each printer, making it possible to reconstruct job status in case of failure at any point.
IDC analyst Josselyn notes that transitions away from the mainframe typically encounter such issues, as job management and recovery were solved in the mainframe world long ago and are now often taken for granted. Vestcom was helped by the fact that it found a hosted-services vendor that supported both the mainframe and distributed-system environments. That way, if the migration didn’t work it would still have a backup option.