gtpc3m1n | Concepts and Structures |
The purpose of module storage is to hold programs and data that are requested by Entries and then transferred to main storage for use. The performance of a TPF system is primarily dependent on the number of file storage requests and the time required to seek and transfer them from a module to main storage. The number of requests is largely determined by application design. The seek and transfer time includes the amount of time taken to process the request by the TPF system, the time in queue for the device, the time required to find the requested data on the physical device, and the time to transfer the data to main storage. Because a device can only handle one request at a time, multiple requests for a particular device must be queued.
The seek and transfer time are based on device characteristics. The queuing time, however, is dependent on data 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.
The factors governing database organization design are:
As queuing increases, the data-request time increases, the life of an Entry increases, and a greater demand is made on working storage. This results in either reduced system performance as viewed by an end user or a system failure because of lack of system resources (working storage).
The organization of the TPF system's data 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 module. Therefore, when Entries access logically adjacent records within a set of data, each record is obtained from a different physical module device.
The fixed record types used by the applications that run in the TPF system are defined during system generation. Contrast this with the batch orientation of data definitions in the IBM MVS system where data sets are defined with a combination of JCL, source code, and supervisory service routines; that is, the complete description of the data set is always deferred until job execution. In the TPF system, the definition of all fixed file records at system generation has the advantage of eliminating the overhead of describing the characteristics of a set of data each time a unit of work is processed. This forces all the files (that is, sets of data) that are required by the online applications to be physically in place and always available, which is simply a characteristic of an online system that runs in real time and accepts random input.
The FACE table (FCTB) is the system table that identifies, for both pool and fixed records, where the various record types are allocated on the physical module devices. The FACE table points to the origins of the various record types, called base addresses.
The functions of file allocation and file address conversion occur at distinctly different times. The allocation occurs once, when a FACE table is generated, to produce the base addresses of the various record types. The file address conversion to a physical file address occurs each time an application (Entry) issues a find or file macro request for a data record. This conversion process uses the FCTB generated by the allocation function.
Before proceeding, you should review the concept of horizontal allocation shown in Figure 26. The purpose of this method of record allocation is to allow a larger number of concurrent accesses to any particular record type, thereby reducing the chance of excessive queuing.
Each logical device type (such as DEVA and DEVB) has its own organization based on the physical characteristics of each device. The records within a given record type are allocated on each logical device type according to the rules of that device type. The records within a single record type can be split across logical device types, allowing each portion to be placed on a different type of device (see Figure 34).
Figure 34. Record Allocation Across Different Types of Module Devices
The TPF system views the entire file space as a repository for holding 4K, 1055-byte and 381-byte records. Within a given record type (for example, 4K fixed records), the TPF system is capable of naming, through the use of database ordinal numbers (DBON), some maximum number of records.
Consider the representation of the fixed file space of n records (database ordinal numbers 0 through n-1) in Figure 35. The number of record types is given as m, where m is less than n.
Figure 35. Total Record Space. Assuming Only One Size Record.
To allocate fixed file space means dividing the entire fixed file space into subgroups of record types, where a subgroup consists of either all small, all large, or all 4K fixed records. The allocation is accomplished by creating a FACE table that associates the base address, called a beginning database ordinal number (DBON), with each record type. Each DBON, after the first one, accounts for the number of records assigned in the preceding record types. For example, in Figure 35 record type 1 begins at DBON 6 and four records are allocated to record type 1.
The next record type (record type 2) begins at DBON 10. In general, each record type is associated with some unique DBON. Notice that the second record (record type ordinal number 1) of record type 1 is at DBON 7 of the overall fixed file space. It is important to notice that:
There is a similar procedure for allocating the pool file space. The record type for a pool file is based on the pool record type (such as SSTx and LDPx).
The online physical file storage is allocated for the different record sizes in proportions that are primarily determined by application design. The sum of allocations of all pool and fixed records comprises the entire online physical file space.
The TPF system ensures that the sequential database ordinal numbers (DBON) do not map into physically adjacent records. It is assumed, in general, that the horizontal allocation of records of a given record type throughout the file storage permits a greater chance for simultaneous accessing than the more conventional, vertical allocation, as shown in Figure 26. This strategy of allocating records of the same type throughout physical storage is based upon the assumption that many Entries are accessing a shared database. Therefore, the TPF system ensures at least a chance for simultaneous accessing of records within a record type by forcing the records within a record type to be spread across modules. The way this is accomplished is simple in concept but somewhat complicated in detail, and is beyond the scope of this publication.
The allocation of records associates successive database ordinal numbers (DBON) with successive modules, cylinders, heads, and records on modules. Consider the example represented by Figure 36 that shows a configuration of two modules, two cylinders, two heads per module, and five records per track. The numbers in parentheses represent database ordinal numbers (DBON). The numbers without parentheses represent the device addresses (that is, the names of physical locations). Consider all access arms positioned to the same cylinder on all modules. Then, an allocation is stated as follows:
This allocation defines the rules that the TPF system employs to map a data record reference (file address) into an address used by hardware. A record type can be allocated across different logical device types with physical, device-dependent values (that is, the number of modules, cylinders, heads, records). The physical, device-dependent values are held in system tables (such as the MFST, FCTB, and pool directories) utilized by programs that perform address mappings.
The combinations of find and file macro service routines, the file address conversion facilities (FACE, FACS, FAC8C, and FACZC), and the get file storage macro service routines must perform the inverse of the allocation process; that is, to convert a record type and an ordinal number into an address used by hardware.
To compute a file address of a data record means the conversion of a record type and an ordinal number into a physical file location. This is accomplished by:
To determine the physical address for record type 1, ordinal number 3, the TPF system must:
The TPF system calculates MCHR by manipulating the DBON of the desired record as follows:
DBON/H*R*M = Q1, E1 (Q1 = Cylinder number) E1/R*M = Q2, E2 (Q2 = Head number) E2/M = Q3, E3 (Q3 = Record number, E3 = Module number)
Where:
To use the example just described:
Where: DBON = 9 DBON/H*R*M = 9/20 = 0,9 C = 0 E1/R*M = 9/10 = 0,9 H = 0 E2/M = 9/2 = 4,1 R = 4 M = 1
Therefore, MCHR = 1, 0, 0, 4 (as shown by Figure 36).
C, H, R, and M are constant values that depend on the geometry and the number of modules. Table 5 uses the following sample values: C=2, H=2, R=5, and M=2. c, h, r, and m are variable values that depend on the value of the DBON and have maximum values of C-1, H-1, R-4, and M-1 respectively.
Where:
Table 5. Determining the Algorithm Relating the Cylinder, Head, Record, and Module to the DBON
Record Number (DBON) | Cylinder (c) | Head (h) | Record (r) | Module (m) |
---|---|---|---|---|
0 | 0 | 0 | 0 | 0 |
1 | 0 | 0 | 0 | 1 |
2 | 0 | 0 | 1 | 0 |
3 | 0 | 0 | 1 | 1 |
4 | 0 | 0 | 2 | 0 |
5 | 0 | 0 | 2 | 1 |
6 | 0 | 0 | 3 | 0 |
7 | 0 | 0 | 3 | 1 |
8 | 0 | 0 | 4 | 0 |
9 | 0 | 0 | 4 | 1 |
10 | 0 | 1 | 0 | 0 |
11 | 0 | 1 | 0 | 1 |
12 | 0 | 1 | 1 | 0 |
13 | 0 | 1 | 1 | 1 |
14 | 0 | 1 | 2 | 0 |
15 | 0 | 1 | 2 | 1 |
16 | 0 | 1 | 3 | 0 |
17 | 0 | 1 | 3 | 1 |
18 | 0 | 1 | 4 | 0 |
19 | 0 | 1 | 4 | 1 |
20 | 1 | 0 | 0 | 0 |
21 | 1 | 0 | 0 | 1 |
22 | 1 | 0 | 1 | 0 |
23 | 1 | 0 | 1 | 1 |
24 | 1 | 0 | 2 | 0 |
25 | 1 | 0 | 2 | 1 |
26 | 1 | 0 | 3 | 0 |
27 | 1 | 0 | 3 | 1 |
28 | 1 | 0 | 4 | 0 |
29 | 1 | 0 | 4 | 1 |
30 | 1 | 1 | 0 | 0 |
31 | 1 | 1 | 0 | 1 |
32 | 1 | 1 | 1 | 0 |
33 | 1 | 1 | 1 | 1 |
34 | 1 | 1 | 2 | 0 |
35 | 1 | 1 | 2 | 1 |
36 | 1 | 1 | 3 | 0 |
37 | 1 | 1 | 3 | 1 |
38 | 1 | 1 | 4 | 0 |
39 | 1 | 1 | 4 | 1 |
The following algorithm maps the values DBON, c, h, r, m, C, H, R, and M for Table 5:
DBON = c(H*R*M) + h(R*M) + r(M) + m
Example 1
What is the value of the DBON if:
c = 1 h = 0 r = 2 m = 1
DBON = c(H*R*M) + h(R*M) + r(M) + m = 1(2*5*2) + 0(5*2) + 2(2) + 1 = 20 + 0 + 4 + 1 = 25
Example 2
Determine the physical file address values for c, h, r and m if the DBON = 24.
For the following equation:
DBON = c(H*R*M) + h(R*M) + r(M) + m
dividing each side of the equation by (H*R*M) provides the following:
24/20 = c + (h(R*M) + r(M) + m)/20 = c, E1 c is the quotient, E1 is the remainder. E1 = h(R*M) + r(M) + m not (h(R*M) + r(M) + m)/20 c = 1, E1 = 4
For the following equation:
E1 = h(R*M) + r(M) + m
dividing each side of the equation by (R*M) provides the following:
4/10 = h + (r(M) + m)/10 = c, E2 h is the quotient, E2 is the remainder. E2 = r(M) + m h = 0, E2 = 4
For the following equation:
E2 = r(M) + m
dividing each side of the equation by M provides the following:
4/2 = r + m r is the quotient, E3 is the remainder which equals m. E3 = m r = 2, E3 = 0, m = 0
Therefore, when the DBON = 24, the physical file address values
c, h, r and m are as
follows:
Table 6. Physical File Address Values When DBON=24
Record Number (DBON) | Cylinder (c) | Head (h) | Record (r) | Module (m) |
---|---|---|---|---|
24 | 1 | 0 | 2 | 0 |