gtps4m36 | System Generation |
The RAMFIL statement is used to specify characteristics of fixed, pool and spare records for TPF database storage devices. The FACE Table is created as a direct result of coding this statement. The order of record groups on disk is determined by the sequence of RAMFIL statements coded in SIP stage I. The RAMFIL statement is required and must be coded in ascending sequence of your file layout. It is recommended that you review information about data organization in TPF Concepts and Structures before coding the RAMFIL statement.
Certain fixed file records are required to have RAMFIL statements coded for them. The specific ones depend on the particular support functions to be included in the system. See Table 16 for the required record types.
See Pool File Storage for information about determining the minimum number of pool directories.
Format
|
Notes:
RECID=#WAARI.
The parameter specifies one or more 'band' numbers to be assigned to the RECID specified by this RAMFIL statement. Each band number must be specified as a decimal number from 0 to 4095, inclusive. This operand must be coded for all RAMFIL macros with PRIOR=1 that are to have FARF3 addresses generated, except those with RECID=SPARE or POOL. This parameter is not valid when RECID=SPARE or RECID=POOL. This parameter is ignored if STAGE=FARF45 is coded on the UFTFTI statement.
Each band number value specified represents 65 536 records. The band number is used in conjunction with the low order 16 bits of a record number to form a unique fixed file address for a record by the FACE program. By keeping the band numbers for a record type constant from one system generation to the next, the records can be physically relocated without the fixed file FARF3 address changing. Thus embedded file addresses need not be changed.
If a record type requires more than one (1) band number (for example, has more than 65 536 records including lower priorities or expansion beyond 65 536 records is anticipated) the band numbers may be divided and coded as:
The band numbers are used in the order in which they are specified. That is, the first band number is used for record numbers 0-65535, the second band number for record numbers 65536-131071, and so on.
A band number can only be used once for each subsystem user. However, band numbers for each subsystem user are independent of any other subsystem user. Band numbers may be shared by subsystem user unique records only. Band numbers may not be shared by processor and I-stream unique records. Therefore, when defining processor and I-stream uniqueness, it is necessary to select a new band number for each instance of uniqueness.
The uft/fti combination is used in conjunction with a record number to form a unique FARF address for a record. By keeping the uft/fti combinations constant from one system generation to the next, records can be physically relocated without the FARF addresses changing. Thus, embedded file address need not be changed.
The uft/fti combination (0,0) is illegal, even though the combinations (0,x) and (x,0), where x > 0, are valid.
If a record type requires more than one (1) uft/fti combination, a list of uft/fti combinations can be coded. For example:
UFTI4=((3,12),(5,24),(3,10))
uft/fti combinations are used in the order in which they are specified, and can be used only once. For instance, notice that the uft/fti combinations are unique in the UFTI4 example statement. The uft/fti combinations must also be unique between the UFTI4 and UFTI5 parameters. They must also be unique between RAMFIL statements.
We recommend that the lowest FTIs be used first for each UFT to conserve space in the FACE table.
This parameter may be coded only for PRIOR=1 fixed file records and for the lowest pool ordinal number (PSON) for a given pool type. The UFTI4 parameter is required if the user wants to define a FARF4 address for a given RECID. The UFTI5 parameter is required if the user wants to define a FARF5 address for the RECID.
The user may want to code UFTI5 in a STAGE=FARF34 FACE table (refer to the UFTFTI statement UFTFTI). Although no FARF5 addresses are created, the ability to migrate will be verified by the offline FACE table generation. This means that the user can put UFTI5 parameters their RAMFIL statements and have the offline table generator check it for them, even though no FARF5 addresses are actually generated. By verifying their UFTI5 statements the user can ensure the FARF5 migration path is intact while still laying out the database for FARF34 migration.
The assembler only allows 255 characters to be coded for a sublist parameter. If more than 255 characters, including parentheses and commas, are coded for UFTI4 or UFTI5, the statement will not assemble. Because information from RAMFIL is not needed during SIP stage I assembly, statements that do not assemble can be commented out. You will need to uncomment these statements before the FACE Table Generator reads them.
The uft/fti combination is used with a record number to form a unique FARF address for a record. By keeping the uft/fti combinations constant from one system generation to the next, records can be physically relocated without the FARF addresses changing. Because of this, embedded file addresses do not need to be changed.
All uft/fti combinations of the form 0,x are illegal.
If a record type requires more than one (1) uft/fti combination, a list of uft/fti combinations can be coded. For example:
UFTI6=((3,12),(5,24),(3,10))
uft/fti combinations are used in the order in which they are specified and can be used only once. For example, notice that the uft/fti combinations are unique in the UFTI6 example statement. They must also be unique between RAMFIL statements.
We recommend that the lowest FTIs be used first for each UFT to conserve space in the FACE table.
This parameter is valid only for the lowest PSON for a 4-K duplicated long-term pool type. The UFTI6 parameter is required if you want to define a FARF6 address. If the UFTI6 parameter is coded, the UFTI4 and UFTI5 parameters cannot be coded.
If POLID is set to ST then the DUPE parameter must be NO.
The higher number indicates a lower priority.
The PRIOR parameter does not apply to POOL and SPARE records.
Duplicate RECID names must not be specified with duplicate priorities within the same uniqueness group. No gaps may exist in the PRIORs defined for a particular RECID uniqueness group.
Example:
RAMFIL RECID=#FRED,RECNO=20,TYPE=LSA,PRIOR=3. RAMFIL RECID=#FRED,RECNO=10,TYPE=LSA,PRIOR=2. RAMFIL RECID=#FRED,RECNO=30,TYPE=LSA,PRIOR=1,BAND=100 RAMFIL RECID=#FRED,RECNO=15,TYPE=LSA,PRIOR=4.
DUMPALTMODE is only valid on the lowest PSON of each pool type and is not valid on RAMFILs with PRIORs greater than 1.
An attribute defines the Subsystem Users, Processors, and I-streams associated with a fixed record ID.
An asterisk '*' is used to specify all Subsystem Users, Processors, or I-streams not yet specified in prior RAMFIL statements. The '*' may take the place of either or all of the attribute specified previously. Unspecified attributes default to '*'. In other words the default is USER=(*,*,*).
The SSUID must have been specified in the SSUID parameter of SSDEF.
For non-MDBF customers a '*' or 'BSS' can be used when specifying SSUID.
The PROCID must have been specified in the SYSID parameter of CONFIG.
The ISN must take a value between 1 and 8.
Notes:
The following are examples of the USER parameter.
This parameter is only valid on PRIOR=1 fixed file RAMFIL statements.
The PSON value specified must not overlap any PSON range for the same DASD pool type. This is true even when going from one device type to another. If PSON is not specified, then SIP will compute PSON as follows:
PSON = highest PSON already defined for this pool type plus 1
For STAGE34 database definitions, PSON recognizes only two categories of pool sizes: small and large. For the purposes of calculating the PSON, 381-byte records are considered "small" while both 1055- and 4K-byte records are considered "large." Therefore, for FARF3 database definitions, 1055 and 4K pool segment PSONs may not overlap with each other.
PSONs must be coded in ascending order for FARF3, FARF4, or FARF5 pool types in a stage I deck unless the OVERRIDE parameter is coded. For FARF6 pools, PSONs can be coded in any order without specifying the OVERRIDE parameter.
Although the SIP calculates a default, it is recommended that this parameter be coded. In Stage FARF3/4 large and 4KB pool records share PSONs, but in Stage FARF4/5 they do not share PSONs. This could lead to the PSONs changing for large and 4KB pool records when the stage is changed from FARF3/4 to FARF4/5.
The value specified for this parameter must be a multiple of 2 (or 0).
If a value greater than 0 is specified, the DASD pool directories will be generated to include pool records residing on the pseudo modules. However, the pseudo module pool record addresses will be in a DEACTIVATED state and, therefore, will not be dispensed by the online system until the file pool programs are told to activate the pseudo modules.
The number of pool records for this segment that can be contained on the pseudo modules must be added to the RECNO parameter value to determine the pool ordinal number range for this segment. See the PSON parameter description above. The pool type (duped/nonduped) and device type duplication (nonduped, fully duped or selectively duped) must be considered in determining the number of pseudo pool records.
(SSUID,PROCID,ISN)
The triplet defines the owning subsystem user, processor, and I-stream combination. The owner of a record must also be specified as a user of the record. An SSUID is required, while the PROCID and ISN specifications are optional. When SSUID would appear alone in parentheses, the specification is simply coded as OWNER=ssu, a subsystem user ID as found in the SSDEF macro. For non-MDBF customers, a * or BSS can be used for SSUID. Information specified by this parameter is used by Data Base Reorganization and Recoup.
The default is the first triplet specified or implied by the USER parameter.
This parameter is only valid for fixed file records. The owner of a set of pools is the first subsystem user, processor, and I-stream.
The default value is 0.
This parameter is only valid for POOL records (RECID=POOL, RECID=POOL6). The value coded for this parameter cannot exceed the number of prime and pseudo modules in the system.
The default is the number of prime + pseudo modules.
This parameter is only for POOL records (RECID=POOL). The sum of LOMOD and NOMOD must not exceed the number of prime and pseudo modules.
The effect of this mechanism is to provide an extension of information associated with a record type. When the record type is accessed, a pointer to the external user data is returned giving a calling program access to that data.
The symbols "CTSD" and "CONK" are reserved and should not be redefined in the external symbol dictionary. This applies to the UFARFx parameters as well.
This parameter is not valid for SPARE records.
This parameter is not valid for SPARE records.
This parameter is not valid for SPARE records.
The effect of the UFARFx parameters is to make user specified information available on an addressing mode basis.
This parameter is not valid for SPARE records.
The effect of the UFARFx parameters is to make user-specified information available on an addressing mode basis.
This parameter is not valid for SPARE records and is only valid when the UFTI6 parameter is also coded.
RAMFIL Parameter Rules
Table 23. RAMFIL Parameter Rules
Parameter | Fixed | Pool | Spare or VTOC |
---|---|---|---|
RECID | Required | Required | Required |
RECNO | Required | Required | Required |
TYPE | Required | Required | Required |
DUPE |
Allowed See note 2. |
Allowed See note 2. |
Allowed See note 2. |
BASE |
Allowed See note 1. | Required |
Allowed See note 1. |
PRIOR |
Required See note 2. | Invalid | Invalid |
PSON | Invalid | Allowed | Invalid |
USER |
Allowed See note 2. | Invalid | Invalid |
INUSE |
PRIOR=1 See note 2. | Invalid | Invalid |
BAND |
PRIOR=1 See note 3. | Invalid | Invalid |
UFTI4 |
PRIOR=1 See note 3. |
Low PSON See note 3. | Invalid |
UFTI5 |
PRIOR=1 See note 3. |
Low PSON See note 3. | Invalid |
UFTI6 |
Invalid |
Low PSON See note 3. | Invalid |
POLID | Invalid |
Allowed See note 2. | Invalid |
PSEUDO | Invalid | Allowed | Invalid |
OVERRIDE | Invalid | Allowed | Invalid |
DUMPALTMODE |
PRIOR=1 See note 2. |
Low PSON See note 2. | Invalid |
OWNER |
PRIOR=1 See note 2. | Invalid | Invalid |
LOMOD | Invalid | Allowed | Invalid |
NOMOD | Invalid | Allowed | Invalid |
UCOMDATA |
PRIOR=1 See note 4. | Low PSON | Invalid |
UFARF3 | Allowed | Allowed | Invalid |
UFARF4 | Allowed | Allowed | Invalid |
UFARF5 | Allowed | Allowed | Invalid |
UFARF6 | Invalid | Allowed | Invalid |
EQU |
Allowed See note 5. |
Allowed See note 5. | Invalid |
RESTORE |
PRIOR=1 See note 4. | Invalid | Invalid |
DEACTIVATE | Invalid | Allowed | Invalid |
|
Examples
None.
References