gtpc3m1q | Concepts and Structures |
The life of a pool record from the application point of view can be described as follows:
The pool macro service routines manage pool file storage by manipulating the pool record bits in the pool directories.
To dispense a pool record means to generate an ordinal number and mark the record as unavailable within a pool directory. The basic principle of dispensing pool records is straightforward. The detailed algorithms found in the system programs are slightly more complicated because of the following:
An explicit description of the pool directory procedures is not given in this publication. However, the TPF system structures associated with these details are necessary to understand pool file management techniques.
See Figure 39. The space allocated on a logical device type for a pool record type is called a pool section. Space for a pool record type can be allocated across several logical device types, in which case there are several pool sections for the pool record type. (Recall the pool record type discussion in Pool Record Types.)
Figure 39. Pool Section. For a Pool Type.
See Figure 40. For a pool record type, several noncontiguous areas can be allocated per device within a logical device type. Each area within a pool section is called a pool segment; therefore, a section can be segmented.
Figure 40. Pool Segments. For a Pool Section within a Pool Type.
See Figure 41. Recall that a pool directory contains the pool record availability bits for a pool record type. Each pool section of a pool record type requires at least one directory record. Depending on the number of pool records in a pool section of a pool record type, several directory records can be required. Each pool segment requires the start of a new directory record; therefore, a segmented pool section requires at least two directory records.
Figure 41. Pool Directory. For a Pool Type with Two Pool Segments.
Application programs use a get file storage macro to request (obtain) a pool record in any one of the standard TPF record sizes. This dispensing of a pool record can be influenced by the pool management techniques of ratio dispensing or pool fallback.
Application programs use the return file pool address request macro request to release pool records (that is, return pool records to the TPF system). At this point, the application program has fulfilled its obligation to return any pool file storage to the TPF system that it no longer requires.
The return file pool address macro service routine is responsible for resetting the appropriate bit within a pool directory record to indicate availability. For short-term pool records, the bit is reset immediately, and the pool record is immediately available for reuse. For long-term pool records, the setting of the bit is deferred because of a negative performance impact to the TPF system.
Because the rate of change to long-term pool directory records is much less frequent than that of short-term pool directory records, and the likelihood of any given long-term pool directory record being in main storage is low, processing of the return of a long-term pool record can be deferred until a period of low system activity. The negative performance impact can be explained by the overhead that would be incurred if it was necessary for the TPF system to retrieve a long-term pool directory record each time, or nearly each time, a long-term pool address was returned.
The processing done by the return file pool address macro service routine is based upon the longevity attribute as follows:
When the pool space consists of several types of devices, ratio dispensing is an attempt to spread the in use pool records across the types of devices to prevent I/O bottlenecks.
Therefore, by definition, for a particular pool type, there is a pool section for each logical device type. Ratio dispensing is the technique used to dispense addresses from the various pool sections of a pool record type based on a ratio factor. The ratio factor specifies the number of addresses to dispense from a pool section before selecting another pool section from which to dispense addresses.
If a depleted pool section (that is, a pool section containing no available addresses) is selected for address dispensing, an alternate compatible pool section is used if possible. This is called pool fallback. Selection of alternate pool sections for fallback processing is done based on a predefined schedule. Pool fallback schedules can provide short-term to short-term, short-term to long-term, or long-term to long-term fallback capability for depleted pool sections.
Multiple directory records are normally associated with each pool section. Consequently, a function called directory reordering can be invoked by the TPF system to process a request for pool file storage.
Directory reordering generally consists of scheduling retrieval (from file storage) of new directory records before the in-use directory records are depleted. This is done when the remaining number of available addresses in the in-use pool directory reaches a predefined critical level called the reorder level. At this point, an Entry is created that invokes the directory reorder mechanism to retrieve new directory records from file storage.
By design, the pool sections for short-term pool records are recycled. This means if the last directory of such a pool section is depleted and if the time interval for recycling has elapsed, the section's first directory is again set up for dispensing with all bits in available status. See Figure 41.
Therefore, applications should not utilize a short-term pool record for a longer period of time than the time interval between recyclings. This criteria is generally satisfied if the record is returned by the end of a TPF system transaction. Otherwise, pool record references could be dispensed a second time while still being used for a previous application request. The pool recycle time interval is dependent upon the application environment's use of short-term pool records and the amount of module space allocated to short-term pools.
The TPF system provides the capability to allocate pool records to more modules than actually exist in the physical configuration. This capability facilitates pool space allocation when the database is expanded by adding more modules.
The addresses on these (future) modules, called pseudo modules, are marked as unavailable in the pool directories. When physical modules are added to the system, and because the pool availability bits are already allocated, it is a relatively simple procedure to begin to use the additional pool records. The procedure is performed by pool directory generation programs that mark the addresses as available.