Introduction to Data Management

Managing Data on the Tandem Systems
2-2 15873 Tandem Computers Incorporated
Concurrent OLTP for
Active Databases
In an active OLTP system, not only must many transactions take place concurrently,
but functionally related operations must be interleaved with each other.
The Tandem systems make this concurrency possible by providing rapid response at
the terminal, specialized application modules called requesters and servers, and the
ability to balance the workload between CPUs to achieve the most efficient
processing.
Rapid Response Time As you sit at your terminal, you see response time as the period that the system needs
to act on your requests. This period begins when you send a request to the system,
and ends when the system responds to that request and prompts you for another.
Obviously, the less time you must wait between requests, the more efficient you
become.
On the Tandem system, the same design features that support high-volume
throughput contribute to rapid response, minimizing pauses between requests even
when the system workload is heavy.
Specialized Application
Modules
A Tandem system treats each running program as a process. A program is a static
group of instruction codes and initialized data residing in a file. A process is a
dynamically running program executing under control of the GUARDIAN 90
operating system.
A user can run the same program on several separate occasions, with each execution a
unique process. Alternatively, several users can run the same program concurrently
on one or more CPUs, with each execution constituting a different process. A Tandem
computer can concurrently run up to 256 system and application processes on each
CPU.
When you enter a transaction at the terminal, two types of processes cooperate to
accomplish the database operations that the transaction requires: requester processes
and server processes. These processes communicate with one another by messages
transmitted through the message system portion of the GUARDIAN 90 operating
system.
Requester and server processes let you tailor an OLTP application for maximum
efficiency. For instance, you might want to divide the application into two processes
that handle entirely different functions:
A requester process that manages the front-end interface by accepting requests
from users at one or more terminals
A server process that manages the database by servicing requests from the
requester process to add, modify, or delete data
In this requester-server relationship, the terminal (requester) process sends a request
to the data-management (server) process, and the data-management process receives
that request and services it.