Record allocation
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 z/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 z/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 capacity of the module in relation to the quantity of data to be contained
- The ability of the module hardware and the z/TPF system to handle requests at a rate consistent with the objectives of system performance.
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 z/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 z/TPF system are defined during system generation. Contrast this with the batch orientation of data definitions in the IBM® z/OS® 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 z/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 2. 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.
The z/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 z/TPF system is capable of naming, through the use of database ordinal numbers (DBON), some maximum number of records.
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 2 record type 1 begins at DBON 6 and four records are allocated to record type 1.
- A fixed file area for holding record types consisting of records of the same size has a set of database ordinal numbers (0 through n-1).
- Each fixed record type has a set of DBONs equal to the number of records designated for that record type.
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 z/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 2. 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 z/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 information.