gtps4m11 | System Generation |
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:
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.
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.
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:
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.
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:
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.