Jane C. Blake,
Digital's transaction processing systems are integrated hardware and software products that
operate in a distributed environment to support commercial applications, such as bank cash
withdrawals, credit card transactions, and global trading. For these applications, data integrity
and continuous access to shared resources are necessary system characteristics; anything less would
jeopardize the revenues of business operations that depend on these applications. Papers in this
issue of the Journal look at some of Digital's technologies and products that provide these system
characteristics in three areas: distributed transaction processing, database access, and system
Opening the issue is a discussion of the architecture, DECdata, which ensures reliable inter operation
in a distributed environment. Phil Bernstein, Bill Emberton, and Vijay Trehan define some transaction
processing terminology and analyze a TP application to illustrate the need for separate architectural
components. They then present overviews of each of the components and interfaces of the distributed
transaction processing architecture, giving particular attention to transaction management.
Two products, the ACMS and DECintact monitors, implement several of the functions defined by the DECdata
architecture and are the twin topics of a paper by Tom Speer and Mark Storm. Although based on different
implementation strategies, both ACMS and DECintact provide TP-specific services for developing
executing, and managing TP applications. Tom and Mark discuss the two strategies and then highlight
the functional similarities and differences of each monitor product.
The ACMS and DECintact monitors are layered on the VMS operating system, which provides base services
for distributed transaction management. Described by Bill Laing, Jim Johnson, and Bob Landau, these
VMS services, called DECdtm, are an addition to the operating system kernel and address the problem.
of integrating data from multiple systems and databases. The authors describe the three DECdtm
components, an optimized implementation of the two-phased commit protocol, and some VAXcluster-specific
The next two papers turn to the issues of measuring TP system performance and of sizing a system to ensure a
TP application will run efficiently. Walt Kohler, Yun-Ping Hsu, and Wael Bahaa-El-Din discuss how Digital
measures and models TP system performance. They present an overview of the industry standard TPC
Benchmark A and Digital's implementation, and then describe an alternative to benchmark measurement - a
multilevel analytical model of TP system performance that simplifies the systems complex behavior to a manageable
set of parameters. The discussion of performance continues but takes a different perspective in the paper on sizing
TP systems. Bill Zahavi, Fran Habib, and Ken Omahen have written a methodology for estimating the appropriate system
size for a TP application. The tools, techniques and algorithms they describe are used when an application is still in
its early stages of development. High performance must extend to the database system. In their paper on
database availability, Ananth Raghavan and T.K. Rengarajan examine strategies and novel techniques that minimize the
affects of downtime situations. The two databases referenced in their discussion are the VAX Rdb/VMS and VAX DBMS
systems. Both systems use a database kernel called KODA, which provided transaction capabilities and commit processing.
Peter spiro, Achok Joshi, and T.K. Rengarajan explain the importance of commit processing relative to throughput and
describe new designs for improving the performance of group commit processing. These designs were tested,
and the results of these tests and the authors observations are presented.
Equally as important in TP systems ad database availability is system availability. The topic of the final
paper in this issue is a system designed to be continuously available, the VAZft 3000 fault-tolerant system.
Authors Bill Bruckert, Carlos Alouso, and Jim Melvin give an overview of the system and then focus on the
four-phase verification strategy devised to ensure transparent system recovery from errors.
I thank Carlos Borgialli for his help in preparing this issue and for writing the issue's foreword.