Animated GIFs by:

What Are We Really Talking About Here?
What will TPF be replaced with ? 

It seems that EDS & Compaq's plans to replace the TPF system at the heart of the Sabre system revolve around a 'concept' known as Zero Latency Enterprise (there is a White Paper on the Compaq site here )

Having read the paper it does not seem to explain anything new over what has been put forward by the Open Systems community for the last 10 -15 years.  The most positive comment I can come up with on the basis of what this White Paper says is that in the period since Unix first tried to break into the Transaction Processing and high-availability (7 X 24 X 365) world dominated by TPF for over 30 years there have clearly been some solidifying of the Unix environment and the creation of sufficient operational tools and environments to enable a sensible comparison with a system as mature and field-proven as TPF.

Heavy use will need to be made of cacheing the information required to satisfy TPF-level individual transaction workloads.  The ZLE Architecture paper discusses what it calls:

"The cluster-aware RDBMS component of the ZLE core can be either the NonStop SQL database running on the NonStop Himalaya platform or Oracle Parallel Server running on the Tru64 UNIX AlphaServer platform. In its role as an ODS, or real-time enterprise cache, it contains three types of data:

State data: current value information, such as a customer’s current account balance 
Event data: detailed transaction or interaction level data, such as call detail records, credit card
transactions, Internet or wireless interactions, and so on 
Lookup data: data not modified by transactions or interactions 

Overall, the database is optimized for application integration as well as real-time data access as opposed to business intelligence. For example, a customer record in ZLE might be indexed by customer ID (rather than by time, as in a data warehouse) for easy access to a complete customer view.

The major functions the database performs within the ZLE architecture are

Dynamic data cache: As a real-time ODS, the database can integrate and cache up-to-the-second
data, such as current account balances or current inventory status, for immediate access by people
and new zero latency applications. This obviates the need for contacting individual production
systems to obtain this information and greatly enhances the performance of the architecture. 
Historical or memory data cache: In addition to current event data, the ODS can supply a recent
(measured typically in months rather than years) event history to be used by new ZLE applications,
such as customer service or e-store applications. Historical data is critical for recommendations based
on customer behavior. 
Robust message store: As an EAI platform for hub-based publish and subscribe message
dissemination, the database caches and queues messages (for example, specific events and their
results) for pushing out to subscribers. Performing publish and subscribe through the relational
database enables the messaging function to leverage the RDBMS platform’s parallelism, partitioning,
and built-in manageability. Priority, first-in/first-out, guaranteed, and once-and-only-once delivery
are all supported. 
State engine: As a state engine synchronized with the business in real time, the database can provide
state engine functions for managing workflow; learning the state of long-running transactions;
viewing the state of business processes, such as where a customer’s order stands in the shipping
process; and so on. "

Beyond this there is also the central processing component of the architecture, the server, or servers, since parallelism is a key 'benefit' of ZLE.

"Parallel execution of functions: Real-time operations start with real-time execution. 
A single system image: For a real-time consolidated view of business, a single, manageable view of
applications and data is necessary. 
Inherent scalability and support for 24 x 7 operations: Once deployed, a ZLE solution needs to expand gracefully and provide the continuous operations that characterize other business-critical,
revenue-enabling systems. 
Robust application server functionality: Includes strong transaction management. 
Support for all leading transports and adapters. "

There is nothing wrong with the sentiment in this extract from the White Paper either.  The capabilities and functionality described here are almost exactly those on which TPF is based and on which TPF users rely.  The question has never been explaining the problem, but solving it, and doing so under the conditions imposed by global distribution and the need for true realtime performance for complex transactions.

Unfortunately there is really no easy way to evaluate the likely success of this architecture in a TPF environment other than to build one and see.

That carries with it one of the largest intrinsic problems faced when replacing all legacy systems, but perhaps especially TPF systems, how to build a full functional model of the applications in order to be able to develop the new generation of applications that will populate the architecture.  Amadeus, one of Sabre's chief competitors is already building next generation applications on Open Systems architectures to offload some of the functionality currently on the TPF central system.  It seems that the Sabre decision commits to offloading effectively all functionality to such Open-architecture platforms.  It might prove wiser to follow the more prudent approach of Amadeus in offloading applications over time rather than to attempt a wholesale re-engineering of the entire service software base.

It may be that the ZLE architecture demands such a global re-write to properly achieve the full potential of the architecture, in which case that may prove a weakness in a real-world implementation on this scale.