gtpc3m1rConcepts and Structures

Multiple Database Function (MDBF)

The multiple database function (MDBF) of the High Performance Option (HPO) feature permits the physical and logical separation of sets of data within the TPF online modules. An example is an airline's reservation application that supports several airlines, each with their own unique reservation records but which share hardware and system resources.

When sets of data are separated physically, a set of data is accessible by a subsystem. When sets of data are separated logically, a set of data is accessible by a subsystem user. When sets of data are separated physically and logically, a set of data is accessible by a subsystem user within a subsystem. Refer again to Figure 27.

A subsystem can support multiple subsystem users. However, it is not necessary to define subsystem users.

The basic subsystem (BSS) is fundamental; at a minimum, the basic subsystem contains the sets of data required by the TPF system for its own operation and, therefore, must always exist. (A TPF system without MDBF is actually operating as a basic subsystem.)

Generating a TPF system with the multiple database function (MDBF) impacts the TPF system services and structures dealing with file management and message routing.

File Address Compute Table (FCTB)

There is one FCTB associated with each subsystem and its associated subsystem users. In addition, it contains a list of the subsystem user names for the subsystem. Each subsystem is given a subsystem ID (SSID) and each subsystem user within the subsystem receives a subsystem user ID (SSU ID). These IDs are used by the TPF system to control the access to data on the physical devices.

Furthermore, pool records are shared among all subsystem users on any given subsystem (in other words, stating this: each FACE table represents one shared allocation of pool records for a subsystem and all fixed record allocations for the subsystem users within the subsystem).

The FACE and FACS programs and the FAC8C macro return the file address for any fixed file record that is accessible from the subsystem user (SSU), processor, and I-stream engine that requested record addressing conversion services (see Figure 42).

Figure 42. Relationship of FCTBs to Subsystems and Subsystem Users


Record ID Attribute Table (RIAT)

There is one item in the RIAT for each record ID defined within any subsystem, and there is a RIAT for each subsystem.

Module File Status Table (MFST)

An MFST exists for each subsystem in an MDBF environment, and contains the information necessary to identify subsystems.

Routing Control Application Table (RCAT)

Although the RCAT is considered part of TPF data communications, which is discussed in Data Communications, it is necessary to describe it briefly here in relation to MDBF.

To ensure that an input message is routed to the appropriate subsystem for message processing, the routing control application table identifies both the subsystem and the subsystem user associated with an application.

Global Area and Global Records

Although the concept of globals has not yet been introduced, it is necessary to describe it briefly here in relation to MDBF. See Globals, for more information.

There are global records for each subsystem user in each subsystem. Also, there is a unique main storage global area for each subsystem user in a subsystem. Note that the use of subsystem user global areas could require a significant amount of main storage.

Summary of MDBF

MDBF introduces the terms subsystem and subsystem user with the following key associations:

Within a loosely coupled complex, a database is considered to be a unique set of fixed and pool record types allocated across a set of modules.