gtps4m11System Generation

Fixed File Storage

The records which need to be frequently accessed and which may hold pointers to data held in the pool areas, are called fixed-file records. A set of data is identified as a fixed record type when it represents a collection of related records. Within the fixed record type the total number of records must be specified and must be designated as small, large, or 4K.

The identification of a set of data as a fixed record type accomplishes several things:

The fixed record types required by the applications which run under TPF should be defined at the time of system generation. Contrast this with the batch orientation of data definitions within MVS where data sets are defined with a combination of Job Control Language, source code and supervisory service routines; that is, the complete description of the data set is always deferred until job execution. 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 to be processed. This forces all the files which are required by the online applications to be physically in place and available, which is simply a characteristic of an online system that runs in real-time and accepts random input.

Each of the records associated with a record type is identified by an ordinal number. Ordinal numbers are meant to indicate the succession of records within a fixed record type. For example, consider a record type, T, and for purpose of exposition let the data in the first 4 records be represented as DATA1, DATA2, DATA3, and DATA4. If a request is made for records 1-4 of record type T, then the system should yield DATA1, DATA2, DATA3, and DATA4 regardless of the physical location of the records. This means that even if the records are not physically adjacent in the physical file storage system, the system should consider these records as the first, second, third and fourth records of record type T.

To accomplish the fixed file organization requires two things:

  1. A system table identifying where the various record types are assigned. The creation of this table is the essence of allocation and must consider the physical device characteristics, system configuration, and the allocation strategy. This main storage resident system table has pointers to the origins, called base addresses, of the various fixed record types. This table is known as the file address compute table (FCTB). It is created using the FACE Table Generator (FCTBG).
  2. System programs generate a physical address given a fixed record type and ordinal number. The mapping of a fixed record into a physical address is accomplished by a combination of I/O service routines and the file address compute program (FACE). Two versions are provided; the first accepts the record type as a symbolic equate called the record type (FACE), the other accepts character input of the record type (FACS). FACS is the preferred interface, because it makes the application code independent of the FCTB. The FACE interface may require the application to be reassembled if the value of the symbolic equate changes.

The preceding functions occur at distinctly different times. The allocation occurs once, at system generation, and produces the system table of base addresses. The mapping of a physical file address occurs each time an application needs to obtain the physical location of a fixed record. The mapping programs use the FACE table generated by the FACE table generator.

The system views the entire file space as a repository for holding 4KB, 1055-byte, and 381-byte records. In a given file configuration, the system is capable of naming, through the use of ordinal numbers, some maximum number of records. Clearly the system can have no more fixed record types than this maximum. In practice, the number of fixed record types is much smaller than the total number of records. Consider the representation of the fixed file space of n records (0 through n-1 ordinal numbers) in Figure 14. The number of record types is given as m, where m is less than n.

Figure 14. Fixed Record Space


To allocate fixed file space means dividing the entire fixed file space into the subgroups of record types (a record type consists of either all small, all large, or all 4K records). The allocation is accomplished by creating the FACE table (using SIP RAMFIL statements), which associates a beginning ordinal number (called the record type base address) with each record type. Each ordinal base address, after the first one, accounts for the number of records assigned in the preceding fixed record type. For example, in Figure 14 record type 1 begins at ordinal number 6 and four records have been allocated.

The next record type (type number 2) begins at ordinal number 10. In general, each record type is associated with some unique ordinal number, k. This unique ordinal number is known as the fixed record type base address. Notice that the second record (ordinal number 1) of record type 1, is at ordinal number 7 of the overall fixed file space in Figure 14. It is important to notice that:

Computing a file address means converting a record type and ordinal number into its file address reference format, or FARF. This is accomplished by looking in the FACE table to find the split that describes the record type and ordinal requested. Fixed file records are loaded from a pilot tape using one of the FACE programs to determine their addresses or they may actually be created in the execution of the online system by an initialization or maintenance program. For more information about TPF DASD addressing, see TPF Database Reference.

RAMFIL Statements for Fixed Record Types

Specifying the characteristics of fixed and pool record types on direct access storage devices is accomplished via the SIP RAMFIL statement. A separate RAMFIL statement is required for each fixed record type, spare record interval, and pool type. The following are the SIP RAMFIL parameters relating to fixed record areas:

RECID
FACE record type

RECNO
Number of records being specified as a group

DUPE
Type of duplication

TYPE
Record size and storage device type

BASE
Starting record address

PRIOR
Priority for split groups

INUSE
Actual vs. spare record types

BAND
Record type band number

USER
Subsystem user owning record (MDBF only option)

UFTI4 UFTI5
UFT/FTI combination for addresses

DUMPALTMODE
A parameter used during conversion of databases

RESTORE
Controls whether record type should be restored or not

UCOMDATA
User record information attached to the FACE table

UFARF3 UFARF4 UFARF5
User FARFx data attached to individual splits

EQU
Record type equate value associated with a record type

OWNER
Owning SSU, processor and I-stream for a record type.

The sequence of the RAMFIL statements determines the sequence of the record groups on file storage. Record types may be divided across multiple device types or placed on noncontiguous locations of the same device type. A separate RAMFIL statement is required for each such division across device types. The PRIOR parameter is used to specify the sequence priority.

The INUSE parameter of the RAMFIL statement permits the specifying of spare record types for later use.

The UFTIn parameter specifies which UFT/FTI combination the addresses are allocated from. The available 4-gigabyte address space should be thought of as sliced into 64 sections. Each section is called a universal format type (UFT). Each UFT is further divided into groups represented by unique format type indicators (FTIs) with the same UFT. One group may be FARF4 while another group may be FARF5. The group may vary in size. There may be 10 FARF4 records followed by 20 FARF5 records, and so forth for the remainder of the UFT slice. The FTI indicator for a particular record in a particular UFT has a length associated with it. This length is used to determine the granularity in which records can be defined. The ordinal included on the end of the address specifies the offset within this group of records where a particular record resides. The UFTIn parameter provides the means for specifying what addressing format should be used to interpret records found within the record types being defined by the RAMFIL statement.

The USER parameter specifies which subsystem users, processors, and I-streams have access to particular record types. By default any subsystem user, processor and I-stream can access any record type. Using the USER parameter access to a particular record type can be limited to specific subsystem users, processors or I-streams.

For example, you may want to monitor I-streams for a certain reason. You can specify groups of record types related to each I-stream that are I-stream unique: USER=(*,*,1) for group 1 accessible from I-stream 1 only, USER=(*,*,2) for group 2 accessible from I-stream 2 only, and so forth.

Alternatively, you might want to specify a group of record types that are only accessible from a certain subsystem user: USER=(SSU1,*,*). This specification says that the records are accessible to subsystem user SSU1 from any I-stream or any processor.

The combination of these three elements can be thought of as forming a three-dimensional solid or matrix. For example:

Figure 15. Three Dimensional Example of Record Uniqueness


describes the relationship between three record types: one is accessible only from subsystem user 2 but on any processor or I-stream, another similarly but only from subsystem user 3, and the third only from subsystem user 1 and only on I-stream 3 but from any processor. The * indicates a given combination applies to any processor, subsystem user, or I-stream, depending on the field where * appears.

Note:
While the combination of these elements, subsystem users, processors, and I-streams can be thought of as forming a three-dimensional matrix, the FACE table actually uses a combination of one-, two-, and three-dimensional matrixes to implement record uniqueness. The FACE table generator (FCTBG) creates a one-, two-, or three-dimensional matrix for each record type depending on how the USER parameter is defined on the RAMFIL macro. When possible, one- and two-dimensional matrixes are used instead of three-dimensional matrixes to save space and reduce the total size of the FACE table.

Consider the example:

   USER=((SSUA,D,*),(SSUB,C,2),(SSUG,*,*),(SSUF,*,6))

shows a record type being specified as being accessible in four different places:

  1. Subsystem User A on processor D and any I-stream
  2. Subsystem User B on processor C and I-stream 2
  3. Subsystem User G on any processor and any I-stream
  4. Subsystem User F on any processor on I-stream 6.

USER parameters specified using a single * can be thought of as vectors. When there are two * characters they can be thought to form a plane.

Specifications using * should be thought of as implicit, while specifications specifying values other than * are explicit. Explicit specifications always override implicit ones.