gtps4m0zSystem Generation

Database Support

The user has the option to install the HPO feature and to make use of the multiple data base function (MDBF), in which case the database of one application or group of applications can be separated from the database of another via the use of subsystems (SS). Using MDBF within a single subsystem, including the basic subsystem (BSS), the user may also have a logical separation based upon the concept of subsystem users (SSU). MDBF allows the database of any given subsystem to be physically separate from that of any other SS, including the BSS. In the rest of this section of the document the term system should be replaced by the MDBF user with the term subsystem. Only in those cases where there is any other meaning will the difference be highlighted for MDBF users.

TPF assumes the responsibility for assigning sets of data to physical devices and converting user data references to physical locations. Thus, the application code will not have to change when the physical configuration of the data files is changed. The system will also be able to arrange the data structure on the physical devices to meet system objectives. TPF favors the objective of performance.

Sharing DASD control units between TPF and another operating system (such as MVS) will have a significant impact on system performance. Contention between operating systems for control unit access can result in busy conditions that will impair the execution of I/O operations.

The purpose of file storage is to hold programs and data that are requested by entries and then transferred to main storage. The performance of a system mainly is dependent on the number of file storage requests and the time required to transfer them. The number is largely determined by the application design. The request time includes the amount of time taken by the control program instructions, the time required to find the requested block on a physical device, the time in queue for the device, and the transfer time. Since each device can only handle one request at a time, multiple requests for a particular device must be queued.

The transfer and seek time are based on the device characteristics. The queuing time, however, is dependent on the file organization. A first step in reducing the queue for any device can be to design a system that approaches equal queue sizes for each device. The average length of the queue on a device can then be reduced by increasing the number of devices.

Two factors governing file design are the capacity of the files in relation to the data to be contained and the ability of the files to handle requests at a rate consistent with the requirements of system performance. As queuing increases, the data-request time increases and the life of an entry increases; thus, a larger demand is made on working storage. This results in either a reduced message rate or a system failure due to a lack of working storage. The following paragraphs describe file storage support:

File storage is organized for 3 record sizes. These sizes (381-byte, 1055-byte, and 4KB) are common to all file storage media and are consistent with the core block sizes in working storage. The difference in size between these and core blocks is due to core doubleword boundary requirements and format flags, which are only maintained in memory, and need not be concerned with the storage media.

The file storage media supported in terms of the basic unit are listed in TPF Migration Guide: Program Update Tapes.

The organization of a file storage system is intended to distribute the records associated with a set of data, called a record type, over physical file storage to reduce queuing time at the devices. Thus, when an application accesses successive records within a record type, each record is obtained from a different physical component.

A record type contains data records that are related by application or by usage. Different record types may be files of programs, inventory records, or payroll histories. Within applications or subsystems there may exist many record types. The same record type may exist in different MDBF subsystems, but it is physically a different set of data records.

Traditionally, MVS record types are called logical files and are customarily assigned to one or more storage media units via a vertical allocation. This has an advantage both in isolating particular files for protection and processing, and in allowing an installation to reduce the number of media units when the file does not have a requirement for continuous availability. This latter advantage is lost in a real-time environment when all logical files must be available at all times. The main disadvantage of such an organization arises when the applications on a particular logical file require a high activity. This results in a queuing problem, especially when using DASD devices. Trying to balance logical files on storage media is very difficult and fails when the application logical file profile changes during operation.

TPF minimizes the problem of uneven queuing on these particular drives by distributing the logical files over all the units of the particular device type (See Figure 10). There can be up to four different device types, each of which is made up of like physical DASD devices. These are referred to as DEVA, DEVB, DEVC and DEVD. This distribution is mandatory and automatic for all DASD devices, with each type having its own distribution. The organization might be envisioned as a group of disk packs, each identical in format and type of contents. The logical files are layers on the packs, each pack with an equal percentage of the total logical file.

Figure 10 represents four disk drives. Device types cannot be intermixed. Residing on these drives are three logical files or record types (XX, YY, and ZZ). Each logical file shares an equal portion of each physical device.

Figure 10. Logical/Physical Disk Device Relationship


The distribution technique in organizing fixed file storage is to place the first record of a logical file on the first physical device, the second record on the second device, and so on to the Nth device, after which the devices are repeated (that is, logical records 1 and N + 1 are on the first physical device). (See Figure 11.)

The purpose of this organization is to allow a larger number of concurrent accesses to any particular logical file than would otherwise be possible, thereby reducing the chance of excessive queuing. It has an additional advantage in that it frees the application design from many of the physical device performance considerations.

Each of the physical device types has its own organization. Logical files are allocated on each type according to the rules of that type. Logical files can be split, with each portion placed on a different device type (see Figure 12). Note that all records allocated to a particular device type are contiguous.

Figure 11. Record Allocation. This is an expansion of Figure 10.

As can be seen, consecutive records are placed on consecutive devices


Figure 12. Multiple Disk Device Type Record Organization


The type of file addresses used by an application program is called the File Address Reference Format (FARF). The techniques used by the application to obtain addresses relate to the record definition on the files. Records on file storage are classified as either fixed or pool records based on how records were requested.

The fixed record area is an area of file storage that contains records whose symbolic addresses can be calculated using a record type and an ordinal number. The record type identifies a set of data within the fixed record area, and the ordinal number identifies a specific record within the record type.

As an example, consider an inventory file for an airline. A record type for flights can be identified and a record can be set aside for each possible flight number on each date for which inventory is kept. Using the flight number and date, the sequence of the appropriate record can be determined. Today's flight 300 would be on the three hundredth inventory record, tomorrow's on the 300 + nth record, where n is the maximum value of a flight number. Obviously this technique is wasteful if the number of records set up far exceeds the requirements of usage. When fixed records are set up for logical files, file storage is allocated and maintained for the exclusive use of each possible record in that logical file.

A different method of obtaining an address must be employed when either the number of records used is far less than those required on a fixed record scheme or the address cannot be calculated. (Although it would be possible in a logical file of names to allot a record to every possible name, it would be unreasonable in terms of the file storage required.) To solve this problem, a number of records are set up in file storage whose addresses are managed by the system itself. When an application needs a new record, the system gives it the symbolic address of one of these records in the pool. When the application is through with the record, its address is returned to the system for recycling. TPF ensures that an address is not given to more than one requester prior to its release. The records set up for this purpose are called pool records.

In order to retrieve a pool record, the application must be able to obtain its address. The common technique used by applications is to form data structures that use fixed records as indexes to pool records. For example, the reservation application uses a fixed record to locate passenger name records in the pool. The index is retrieved, using the flight number and date to calculate its symbolic address. The index is scanned for the passenger's name, and, when it is found, the associated pool address is used to locate the passenger name record. This allows the selection of one of a vast number of pool records with a minimum of file accesses.

Duplication is insurance against loss of critical data due to hardware failure. If a record is duplicated, two copies will be updated whenever file storage is updated. Duplicates are kept on separate devices. When requested, either copy can be used, dependent on queuing on the devices and/or the inability to retrieve one of the copies. TPF supports the duplication of any or all logical files in both the fixed and the pool areas.

When using the loosely coupled (LC) facility of the HPO feature, be aware that record duplication presents a unique situation because it requires the use of the external lock facility (XLF). Even if a record is duplicated, if it is retrieved with a hold, only the prime copy is retrieved. The concept of least queuing for either the prime or duplicated copy in a non-LC system is not employed. The reason for this is that the locks for the record, maintained by XLF, are only maintained for the prime record. If this was not the case, one processor could lock the prime record on one CU but another could lock the duplicated copy on another CU. The duplicated copy is only used when there is a failure on either the prime CU or DASD device or for record retrieval without the hold option where least queuing is still used. For the hardware error condition the prime locks are copied from the prime CU to the CU of the duplicated record to ensure that only one processor is allowed to hold a record at any given time.

The rest of this section is subdivided into sections addressing the various data base device types and record types. Database device addressing and database allocation are addressed in Database Device Addressing and Database Allocation respectively, due to the interdependence of the various device types and record types on the overall database design.