gtpd1m0dDatabase Reference

Mapping FARF Addresses

During FACE table generation, the details of the specific address formats to use for each fixed and pool record type are assigned. For FARF3 fixed records, one band number needs to be assigned for each 64K (65 536) ordinal numbers. Because there is an upper limit on bands, there is an upper limit to the number of fixed record types that FARF3 can map. Consider an installation that insists on 4096 fixed record types; in this case each record type is restricted to 65 536 ordinal numbers. At the other extreme, consider an installation that insist on a single fixed record type; here, 4096 blocks of 65 536 ordinal numbers can be allocated to 1 record type.

In FARF4, FARF5, and FARF6, each UFT/FTI combination has a specific address capacity based on the size of the FTI associated with the UFT. Depending on the number of records needed for a record type, you must assign enough UFT/FTI combinations to map this number of records.

Assigning bands and UFT/FTIs to record types produces a mapping of each ordinal number in a record type to a specific FARF address.

FARF3 pools were left out of the preceding discussion because there is no FARF descriptor related to each pool ordinal (where a descriptor is a band or UFT/FTI). The control bits in the pool address are the only mapping from a record type to a pool address. By inspecting a FARF3 pool address the specific ordinal and the pool type it belongs to are revealed. The relationship between record types and their descriptors needs to be known to determine this level of information from any other FARF address. The disadvantage of FARF3 is the limit on addressing capacity because of the presence of control bits. This disadvantage decreases with FARF4 and does not exist with FARF5.

Regardless of the address format, generating a FARF address for a fixed or pool record is done identically. The record type of the record creates an index into the FACE table.

Note:
Pool records have record type names and record type equate values that are assigned to them by the FACE table generator.

A record type can be in one of two forms. It can be an 8-character string if you use the FACS interface or it can be an equate value if you use the FACE interface. If it is a character string, the name is hashed and an index into a hash table is created. The hash table entry points to a name table entry. If the record type name in the name table does not match the record type name that was specified, a linear search is performed until the correct name table entry is found. The name table entry then points to a split chain header in the split chain header array. If the record type is an equate value (FACE interface), this value is used directly as an index into the array of split chain headers. The hash and name tables are not used by the FACE interface. Once the split chain header is found, the dispense mode indicator is checked to determine which type of FARF address is currently being dispensed. The current dispense mode determines which chain of splits to follow. If the record type is shared, the split chain header points directly to the chain of splits as shown in Figure 2. If the record type is unique, the split chain header points to a matrix that contains pointers to unique sets of splits. If splits do not exist for the current dispense mode, the alternate dispense mode splits are used. The input ordinal number is used to determine which split in the chain of splits maps the input ordinal number. If the requested ordinal is not in the range that is mapped by the current split, a pointer to the next mapping is used to access another split. When the split in which the requested ordinal is mapped has been located, the descriptor that is contained in the split (either a band or UFT/FTI) is concatenated with the result of subtracting the requested ordinal from the first ordinal mapped by this descriptor. (This subtraction gives the relative position of the requested ordinal in the descriptor mapping.) Figure 2 shows this process.

Figure 2. FARF Address Generation


FARF addresses are given to application programs to symbolically refer to specific locations in the database. When a find or file request is made to the database, the FARF address must be converted to a physical location reference. When a FARF address needs to be used to access a physical location, the descriptor field of the address is used to index into a conversion table. A band is a direct index into a band conversion table; the UFT/FTI conversion is a 2-stage lookup. The pointer that is retrieved from the appropriate conversion table addresses the first FACE table split where this descriptor begins mapping the record type. Adding the starting ordinal in this split to the ordinal field in the FARF address re-creates the ordinal number in the record type. If the FACE table split that is accessed first from the pointer in the conversion table does not map the reconstituted ordinal, the next field is used to scan for the correct split. With FARF3 pool addresses, there is no conversion table; the control bits of the address are used to determine the pool type. The PDSCA is used to convert the pool type to pool record type equate value. The rest of the file address is the pool ordinal number. Once the record type and ordinal are known, the process described above to create a file address is used to find the correct split. The base DBON in the correct split is added to the record type ordinal number to produce the actual value that is used to map to a physical location on the database. Figure 3 shows the decoding of FARF3 fixed addresses. Figure 4 shows the decoding of FARF4, FARF5, and FARF6 addresses. See TPF Concepts and Structures for a detailed discussion of the database allocation rules.

Figure 3. FARF3 Fixed Address Decode Procedure


Figure 4. FARF4, FARF5, and FARF6 Fixed Address Decode Procedure


The FARF3 format for fixed files is band number dependent. FARF4, FARF5, and FARF6 formats for both fixed and pool files are UFT/FTI dependent. Band and UFT/FTI numbers must continue to be associated with the same record types from one system generation to another. This ensures that any embedded FARF address will continue to refer to the same record even though the record may have been physically relocated.

The FARF addressing scheme was designed so that migrations would be easier. FARF4 and FARF3 are used together. When all the FARF3 addresses in the system have been converted to FARF4 addresses, the system can be made to run in FARF4 mode only. Similarly, when FARF5 addresses are added to the system, FARF4 and FARF5 addresses can coexist. When all the FARF4 addresses have been converted to FARF5, the system can be made to run in FARF5 mode only. This makes it easier to convert large databases all at once. FARF6 is independent of FARF3, FARF4, or FARF5, and can be used concurrently.