Transaction Processing Facility
| Company type | Software product |
|---|---|
| Industry | Computer software, Operating systems |
| Founded | 1979 |
| Founder | IBM |
| Headquarters | United States |
| Products | Real-time operating system for mainframes |
| Parent | IBM |
Transaction Processing Facility (TPF) is an IBM real-time operating system designed for mainframe platforms, including the zSeries and System z9. It is optimized for rapid, large-scale transaction processing, efficiently managing continuous streams of straightforward transactions over broad network infrastructures.
In contrast to other transaction processing solutions such as IBM's CICS and IMS, TPF is distinguished by its capacity to handle exceptionally high transaction volumes, support a vast number of simultaneous users, and deliver swift response times. It underpins essential systems like VISA credit card authorization processes during peak retail periods.
The airline industry extensively utilizes TPF through its passenger reservation software, the Programmed Airline Reservations System (PARS), along with its global counterpart IPARS. While PARS operates as an application layer, TPF serves as the foundational operating system beneath it.
An optional but significant enhancement is the TPF Database Facility (TPFDF), which boosts database functionality. Additionally, IBM created the ALCS to enable TPF capabilities within the more prevalent mainframe OS MVS, now referred to as z/OS.
History
Originating from the Airline Control Program (ACP), a complimentary software package developed during the mid-1960s in collaboration with major North American and European airlines, TPF was commercialized by IBM in 1979 as a licensed product with applications extending beyond the airline sector.
Traditionally built around the IBM System/370 architecture using assembly language for optimal performance, many TPF applications still rely on assembler code; however, modern releases encourage programming in C. The language SabreTalk, once created specifically for TPF development, has since become obsolete.
The latest iteration, z/TPF V1.1, was launched by IBM in September 2005, introducing 64-bit addressing capabilities and requiring development tools based on 64-bit GNU standards.
Supported compilers for z/TPF include the GCC compiler alongside DIGNUS Systems' C++ and Systems/C offerings, which simplify transitioning from TPF version 4.1 to z/TPF.
Users
Prominent organizations employing TPF encompass Sabre for reservation management, VISA Inc. for transaction authorization, American Airlines, American Express for authorizations, DXC Technology's SHARES reservation system, Amtrak, Marriott International, Travelport (including Galileo, Apollo, and Worldspan), Citibank, Italian rail operator Trenitalia for reservations, as well as Delta Air Lines and Japan Airlines for both reservations and operational functions.
Tightly coupled
While IBM's earlier model, the 3083, was engineered to run TPF on a "fast... uniprocessor," current TPF implementations support multiprocessor configurations comprising several CPUs known as instruction streams or I-streams. Operating multiple I-streams within a Logical Partition (LPAR) is described as tightly coupled, following a symmetric multiprocessing (SMP) model without distinctions such as those found in NUMA architectures.
To balance workload effectively, incoming transactions are assigned to the I-stream exhibiting the least current demand. In loosely coupled setups involving multiple multiprocessor CPC units (physical machines housed within one cabinet), SMP applies within each CPC independently, while communication and resource sharing across CPCs follow alternative protocols.
Within TPF's design, all memory is shared among I-streams except for a dedicated 4KB prefix area. When data segregation by I-stream is necessary, developers allocate memory partitions subdivided according to the number of I-streams and access specific segments based on the active I-stream identifier.
Loosely coupled
TPF can operate across multiple IBM mainframes, spanning from a single to several I-streams, all utilizing a shared database. A system with up to 32 mainframes accessing one TPF database is referred to as a 32-way loosely coupled configuration. The most basic loosely coupled arrangement consists of two IBM mainframes sharing one DASD (Direct Access Storage Device), with the control program loaded in memory on both machines, enabling either mainframe to access the DASD's programs or records.
To ensure serialized access to data records in loosely coupled environments, record locking is crucial. When a record is held by one mainframe, other systems are blocked from accessing it until it is released. In tightly coupled configurations, this mechanism is managed through the Record Hold Table. For locks managed outside the mainframe, within DASD control units, external locking processes are necessary. Historically, locking was implemented via RPQs like LLF (Limited Locking Facility) and its successor ELLF (Extended Limited Locking Facility), which were ultimately superseded by the Multipathing Lock Facility (MPLF). Running clustered (loosely coupled) z/TPF demands MPLF on all disk control units or an equivalent device such as a Coupling Facility.
Records that require strict record locking are those accessed simultaneously by multiple processors. In TPF, records are distinguished by their record type and ordinal. For instance, if a record type 'FRED' has 100 ordinals, the file address for ordinal '5' remains consistent across all processors, making record locking necessary to avoid concurrent access issues.
All processor shared records point to an identical file address and physical location on DASD.
Processor unique records
Processor unique records are designed so that each processor within the loosely coupled system has its own distinct file address for any given record type and ordinal. For example, 'FRED' ordinal '5' would correspond to different physical addresses on separate processors, thus removing the need for locking between processors.
What TPF is not
TPF should not be mistaken for a general-purpose operating system. It is specifically engineered to handle transaction input messages and produce output messages on a one-to-one basis at extremely high throughput with minimal latency.
The system does not include native graphical user interface capabilities and has never supported direct graphical displays since such features would consume vital real-time processing resources. Its user interaction is conducted via command-line interfaces on simple text terminals without mouse-driven pointers, windows, or icons—exemplified by the Prime CRAS (Computer Room Agent Set), which functions as the operator’s console. Communication with operators relies solely on character-based messages. Graphical operator interfaces are provided through external solutions like TPF Operations Server. End-user graphical interfaces must be delivered by external systems that interpret character data and transform it accordingly.
As a purpose-built OS, TPF excludes compilers, assemblers, text editors, or desktop environments commonly found in general-purpose platforms. Source code for applications is maintained and compiled externally—since z/TPF version 1.1, Linux serves as the supported build environment requiring executables in ELF format compatible with s390x-ibm-linux.
Operating TPF necessitates knowledge of its Command Guide because it lacks an online command reference or help system. IBM’s system administration commands are categorized as "functional messages" identified by a "Z" prefix ("Z-messages"), while other prefixes are reserved for customer-developed commands.
Due to TPF’s headless multiprocessing architecture, debugging follows a distributed client-server model since halting the entire system for debugging is impractical. Various third-party debugger tools exist with differing protocols and capabilities—examples include Step by Step Trace from Bedford Associates and CMSTPF, TPF/GI, and zTPFGI from TPF Software, Inc. IBM’s own debugger is integrated within the IBM TPF Toolkit integrated development environment (IDE).
Overview of TPF
TPF is engineered for highly efficient message routing across supported networks, directing data either to alternate destinations, applications, or enabling rapid database interactions.
Data Records
In the past, TPF data conformed to fixed record sizes of 381, 1055, or 4K bytes, dictated by the physical DASD block dimensions. This approach minimized overhead by preventing the fragmentation of large data into smaller pieces during file handling. IBM hardware input/output operations utilize channels and channel programs, and TPF produced extremely compact and efficient channel programs to optimize performance. Early storage limitations compelled TPF applications to deliver robust capabilities while using minimal resources.
Nowadays, these constraints have largely been lifted. Records smaller than 4K bytes remain only for backward compatibility. Technological progress in DASD devices has equalized the efficiency of reading and writing 4K records with smaller ones, and increased storage capacities have diminished the need to tightly pack data.
Programs and Residency
Traditionally, TPF program segments corresponded to the 381, 1055, and 4K byte record sizes. Each segment occupied a single record; complex applications consisted of dozens or even hundreds of such segments. For around forty years, segments were not link-edited but loaded with self-resolving relocatable symbols, which restricted direct addressing across segments. Control flow between segments was managed through the ENTER/BACK system service.
In the early days of ACP/TPF (circa 1965), limited memory necessitated a distinction between file-resident and core-resident programs—only frequently accessed programs stayed in memory, while others were loaded as needed.
With the arrival of C support in TPF 3.0, the existing segment conventions were maintained; however, this proved unsuitable for more complex software. TPF 4.1 introduced fully linked load modules, compiled using the z/OS C/C++ compiler and linked via IEWL, resulting in z/OS-compliant load modules incompatible with traditional segment formats. The TPF loader was enhanced to accommodate these new formats, while assembly language programs continued to use segment structures, creating a division between assembler and high-level language codebases.
Starting with z/TPF 1.1, all programming languages were unified under a fully link-edited model conforming to the ELF standard. The concept of segments was phased out; programs of any size and language could be linked into shared objects. Legacy software benefits from increased efficiency through this repackaging—internal calls within shared objects have shorter runtime paths than system service invocations. Additionally, shared objects facilitate writable data sharing through copy-on-write, supporting TPF's reentrancy requirements.
The previous distinction between file- and memory-resident programs was removed as z/TPF aims for all programs to remain resident in memory at all times.
To accommodate high-level language features such as stack-based memory allocation and recursion, z/TPF optionally extends call stacks for assembly routines, reducing memory usage pressure.
Currently, all z/TPF executables are distributed as ELF shared objects.
Memory utilization
At the outset, memory allocation relied on fixed-size blocks of 381, 1055, and 4 KB, which streamlined the process by removing standard overhead concerns. Developers chose the appropriate block dimension, while TPF maintained available blocks through linked lists. Physical memory was divided according to block sizes, guaranteeing that blocks were assigned and freed within their respective segments without the need for compaction or garbage collection.
With increasing application complexity and the introduction of C language support allowing variable-sized allocations, TPF transitioned to heap-based memory management. To minimize overhead, memory was structured into 4 KB frames (expanding to 1 MB frames under z/TPF). Applications requesting memory were allocated the required number of consecutive frames to meet their size specifications.
Bibliography
- Transaction Processing Facility: A Guide for Application Programmers (Yourdon Press Computing Series) authored by R. Jason Martin (Hardcover - April 1990), ISBN 978-0139281105
External links
- z/TPF (IBM)
- TPF User Group (TPF User Group)