Mar 30 ’10
TPF: Modernizing the “Other” Operating System
Born in the ‘60s as a joint project between IBM and Sabre (the company that developed the Sabre computer reservations and global distribution system used by airlines), Transaction Processing Facility (TPF) is a somewhat obscure operating system that, like some legacy applications, has modernization issues but is so valuable to its customers that simply killing it isn’t a viable option.
TPF, both older versions and the latest 64-bit version, z/TPF, remain treasured in the travel, transportation, and finance industries because it’s simply unbeatable at the task it specializes in—processing highly I/O-intense transactions with extremely low latency and outstanding reliability. While strong in those areas, TPF isn’t adept with computational transactions and batch processing; those types of tasks are typically performed in concert with TPF in the back-office environments of z/OS, CICS, and IMS.
IBM is anxious to migrate sites to z/TPF with its new access to open architecture; the company has designated an end of service date for TPF 4.1 as December 2010. Two case studies presented in this article suggest that Connie Walberg, IBM’s Product Line manager for TPF and z/TPF, is justified in predicting increased momentum in TPF shops moving to z/TPF.
”These shops want the ability to modernize their applications by exploiting SOA and Web services,” Walberg says. “z/TPF allows them to do this, and we’re actively pursuing the z/TPF market.”
Before examining the experiences, insights, and plans of two prominent TPF customers, Marriott International and InterContinental Hotels Group (IHG), let’s review the evolution of TPF, which used pieces of an air traffic control system as its starting point, and z/TPF, its successor.
Valid Claim to Fame
Though it’s seldom mentioned in the trade press, and little is said about it in general mainframe user forums, TPF is known for its high-performance transaction processing. It accommodates tens of thousands of transactions per second, supporting hundreds of thousands of users with often subsecond response times. Originally designed for the airline industry to handle transaction-intense reservation systems that had to be enormously time-sensitive, TPF, and its latest incarnation, z/TPF, is alive and well because nothing else does what it does.
“Sites that use TPF are very concerned about rapid response time on transactions,” says David Boyes, president and CTO of Sine Nomine Associates. “They might be working with several databases throughout the world, orchestrating a transactional sequence that will tell a customer how many flights are available to a particular destination. General-purpose operating systems simply don’t provide the same quality of service.”
Indeed, the strengths of TPF are its faultless reliability in inexpensively processing large numbers of transactions, and its reduced exposure to data corruption. This is because TPF operates as an all-inclusive composite of applications, operating system, and data in a single copy. In addition to travel and transportation firms, financial institutions use TPF for memo posting, deposits, retail authorizations and transactions, balancing, and clearing. Travel industry services that offer Internet queries use TPF for booking transactions and ticketing; the system’s low latency and ability to load applications and systems while running are compelling benefits that have yielded a strong customer base in the U.S. and Europe, according to Walberg.
But all that performance comes with some high costs.
“TPF is fairly complex to maintain, and it isn’t an operating system that many sites are comfortable taking on,” Boyes says. “There’s a small trickle of new sites adopting TPF, but they’re doing this in the face of a skills shortage of staff qualified to work on TPF—and paying premium prices for that staff’s service.”
Finding and retaining skilled IT professionals has been a primary concern for TPF sites.
Important TPF skills include the ability to decompose highly complex tasks into small pieces, which requires strong understanding of high-performance IBM mainframe computing environments. In addition, both C and C++ skills are needed for applications, and skill in assembleras the gl ue that bonds all the various software services together.
No Longer a Silo
To address these issues, IBM introduced a new release of the operating system, z/TPF, which moves TPF into a modern 64-bit architecture and, as a result:
- Eliminates TPF 4.1’s insufficiencies for use with Web services, C++, and Java
- Relieves memory constraints, which allows sites to take advantage of Service-Oriented Architecture (SOA)
- Supports modern open source development toolsets such as Eclipse, which is meaningful because it provides relief to sites facing dwindling staff expertise to support a highly strategic system.
“We opened up [TPF] so z/TPF could be leveraged as an enterprise solution without losing any of its original service goals,” says Rich Szulewski, marketing manager for IBM WebSphere Application Infrastructure on z/OS. “The end goal was a z/TPF product that no longer is an isolated ‘silo’ in the enterprise. Instead, z/TPF operates in concert with open standards.”
The combination of removing memory constraints and support for more application development toolsets opens the TPF environment to more programming resources.
“In the past, there was just CMS [Conversational Monitor System],” says Boyes. “With z/TPF, programming toolsets have opened up to include the Eclipse tools and other toolsets that have resided in the Linux environment. This opens up possibilities for sites to bring on new programming resources for z/TPF.”
Now, customers such as Marriott and Intercontinental can consider z/TPF in the context of what Szulewski terms “right platforming,” a process involving requirements evaluation and the selection of the operating system and supporting resources best suited to those needs. For many travel and financial industry customers, that means retaining the transaction processing capabilities of z/TPF and doing so, Szulewski says, “with full knowledge that z/TPF can work with a batch interface and is reusable.”
Moving TPF application development into the open world—by adopting toolsets for developers such as the GNU General Public License (GPL) operating system and Eclipse—also helps alleviate the skills shortage, which is perhaps the top concern of TPF shops.
“TPF shops [can now] use software developers coming out of college who already have exposure to tools such as Eclipse,” says IBM’s Bill Suppan, TPF technical consulting IT specialist. “We’re also wrapping legacy Assembler code in SOA and Web services, which makes that native code easier for new developers to incorporate.”
Of course, that’s all good news for long-time TPF customers such as Marriott International, a company now in the midst of moving to z/TPF, and IHG, which is considering following Marriott’s example.
Processing business at the rate of $3,000 per second, Marriott relies on TPF to drive its worldwide hotel reservation system. The company uses a System z9 with five CPUs dedicated to TPF.
“We also share a z/VM LPAR with TPF guest systems for application and performance testing purposes,” says Misha Kravchenko, vice president of Reservation Systems, Information Resources.
Kravchenko explains how, in the z/VM environment, TPF applications are taken after unit testing and then run through workload tests that have been carefully scripted beforehand.
“We check the applications for performance, we regression test, and we perform final QA [Quality Assurance] on TPF applications,” says Kravchenko. “The z/VM environment on System z allows us to easily do this.”
Each TPF program has its own copy for testing purposes, and Marriott developers use CMS to edit code under z/VM. Marriott IT is making a gradual transition to newer development tools both to leverage the benefits of open tools such as Eclipse and to ease concerns about staffing issues.
“We’re migrating to open toolsets in a little longer timeframe than normal,” says Kravchenko, “But we’re coordinating this transition while we move to z/TPF, and we’re also incorporating in-house staff training in the new methodology as part of this transition.”
Marriott IT plans to migrate production to z/TPF in 2010; they recently converted internal staff to z/TPF development using Eclipse. The migration plan isn’t without certain challenges.
According to Kravchenko, one of the main challenges they face as they migrate to z/TPF, which is a 64-bit operating system, is having to use new compilers. ”This means compiling source code under both compilers and then seeing how the expanded memory of the new operating system works with our existing software,” Kravchenko says.
Marriott’s current hotel reservation system processes 1,200 transactions per second, with less than 2-second response time for 99 percent of all transactions, so ensuring the same level of performance under a new operating system version with a new compiler is no small task. Nevertheless, z/TPF offers new commercial opportunities for Marriott in the systems area that it can’t realize with TPF 4.1.
Kravchenko says that with the TPF-z/TPF platform changes under way, Marriott’s entire hotel reservations system now processes eight times as many transactions as it did seven years ago, yet at a lower cost.
“We’ve chosen to retain our core transaction processing on TPF, which provides us with 24/7/365 uptime at a performance level of 99.99 percent,” says Kravchenko. “When you spread this cost over the number of transactions we have grown by, the system has actually become less expensive to run.”
The IT skills at Marriott important in this environment include a detailed understanding of all the things a real-time, high-volume transaction processing system does. Among these are massive parallel access to the same database, subsecond response times, efficiency of transactions, and knowledge of thread-based processing.
“Once we complete the migration to z/TPF, we will begin to see the real benefits of 64-bit application processing,” says Kravchenko. “It will move us to a truly scalable computing environment that also will allow us to convert system interfaces to callable services.”
With 4,300 hotels worldwide and an online transaction processing rate of 2,000 transactions a second, IHG adopted TPF 40 years ago and has never looked back.
“Every second, three guests are checking in,” says Alex Grigorian, IHG’s vice president of Enterprise Technology. “TPF is the heart of our central reservation systems.”
Like Marriott, IHG is considering migrating to z/TPF.
“TPF has limitations … and the total cost of ownership isn’t low,” says Grigorian. “But TPF is just fantastic, and we won’t compromise the business.”
Part of TPF’s value as a transaction processor for IHG is TPF’s ability to have a database, which it believes is one of the best for rapid transaction processing. IHG also has decades of intellectual investment in its reservation system that makes the system one of the best in the business.
“We think of these benefits because … TPF is an expensive operating system to run,” says Bryson Koehler, vice president of Revenue and Guest Technology at IHG. “The majority of our code is in Assembler, and this can get expensive to maintain. We’re considering moving to z/TPF, but we also know that a migration will be very costly because of the number of regression tests and recompiles it will entail.”
Like other TPF shops, IHG admits it has considered moving off the TPF platform into an alternate environment such as distributed Java. “But we’re a very legacy-oriented shop, and it’s hard to argue with a transaction processor that has proved itself over and over again, and that has been so successful for our business.”
IBM’s release of z/TPF comes at a time when many sites are well under way with initiatives that leverage Linux with z/OS with virtual Linux on the System z. In this environment, the same shops also run pre-production multiple test systems for TPF that are virtualized under z/VM. They have staff already working on other platforms, and already trained in both the z/OS and Linux worlds. With this skills “jump,” they can move right into z/TPF.
The approach works because sites using TPF also are very likely to run z/OS and z/VM.
“TPF does a small number of things very quickly, but there is a limit as to how many tasks can be assigned to a single system instance,” says Boyes. “This is why you are very likely to also find z/OS in a TPF shop, which is used to process any transactional data that doesn’t have a hard real-time processing requirement—and of course, z/VM, which is used to both test and supply many TPF systems to do certain tasks.”
Boyes further clarified that TPF can be run for time-critical tasks outside the z/VM environment by using a Logical Partition (LPAR). In this context, TPF often is a front-end to CICS and talks to a series of time-critical remote processing machines such as those processing credit cards.
“The deployment is done this way because z/VM introduces some overhead,” says Boyes. “There are some systems that simply won’t tolerate this overhead—[such as] credit card processing or air traffic control. … What’s really remarkable about TPF is that when you’re building a TPF application, you’re actually constructing an entire system, with the operating system, application, data management and I/O management all rolled into one. Then, you test the TPF system under z/VM.”
Such benefits may prove enticing to new customers, just as they have to Marriott, IHG, and other veteran users.
”We also are getting new TPF customers in emerging markets where there’s very rapid transaction growth,” says IBM’s Walberg. “As Radio Frequency Identification (RFID) grows globally, with input coming in from remote devices around the world, something also has to be in place to gather all these transaction pieces for processing. TPF has this capability, and it hasn’t gone unnoticed.”
TPF may not remain obscure indefinitely as that “other” operating system; because of timely enhancements in z/TPF, it may even flourish.