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.
E-mail
Printer Friendly
Reprints
(InfoWorld) - In the litigious world we live in, deploying a unified communications platform in your enterprise could...
