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.