VFA candidate record selection
Records are identified as VFA candidates in the record ID attribute table (RIAT). Use the ZRTDM MODIFY command to define fixed file records or pool records as VFA candidates. Use the ZRTDM DISPLAY command to display RIAT information for the records. See z/TPF Operations for more information about the ZRTDM MODIFY and ZRTDM DISPLAY commands.
Note: Record ID X'00FF' describes the candidacy of all programs.
Because all programs are core resident, ensure that you define this record
ID as a non-VFA candidate by coding VFAF-NO on the RIATA ID macro. This ensures
that VFA resources are not used when programs are loaded in core. See z/TPF and z/TPFDF System Generation for more information
about the RIATA ID macro.
You can define each record group with the following attributes:
- Delay filing
- When an application program issues a FILEC or FILNC macro for a delay
filing candidate, the record is copied to VFA, but the updated record is not
filed physically to DASD. This reduces the amount of physical I/O activity
when VFA candidate records are filed repeatedly. The record is filed physically to DASD during the following conditions:
- The VFA buffer is being moved to the reserve chain because it failed the buffer reuse threshold value test and the size of the reserve chain has fallen below the percentage specified. This is known as force filing.
- The VFA buffer has not been referenced and is required for another VFA candidate record (age out).
- The z/TPF system is cycling below CRAS state after the ZCYCL command was entered.
- The z/TPF system is cycling below CRAS state after the ZRIPL command was entered.
- The z/TPF system is cycled to 1052 state after a ZRIPL command with the BP parameter specified is entered or because of a catastrophic system error resulting from a software IPL.
- The ZVFAC DISABLE command is entered.
Note: For short-term pools, the z/TPF system first checks the delay file threshold value to determine whether to actually file the record or to just remove it from VFA. See Delay file threshold for more information.When a FILUC macro is processed, the delay filing attribute is handled in one of the following ways:- If the z/TPF system is running on a uniprocessor, delay filing is in effect.
- If the z/TPF system is running in a loosely coupled environment and the ZRTDM MODIFY command with the LOCKF parameter specified as DASD is entered, the delay filing attribute is ignored. The request is handled as an immediate file.
- If the z/TPF system is running in a loosely coupled environment and the ZRTDM MODIFY command with the LOCKF parameter specified as PROC is entered, delay filing is in effect and the updated copy remains in VFA on that particular processor.
In a loosely coupled environment, this record is not synchronized between processors; that is, other processors accessing this record will not see the version of this record in VFA on any other processor.
- Synchronized delay filing
- Records are handled the same way as normal delay filing records described previously except that a synchronized delay file candidate is filed when another processor requests the record and database consistency can be maintained if multiple processors update the record.
- Immediate filing
- FILEC, FILNC, and FILUC macros are processed in the usual way; the record is filed physically to DASD. Immediate filing occurs for delayed file records when the z/TPF system is in 1052 state. In a loosely coupled environment, this record is not synchronized between processors; that is, other processors accessing this record will not see the version of this record in VFA on any other processor. See z/TPF General Services for more information about the FILEC, FILNC, and FILUC macros.
- Synchronized immediate filing
- Records are handled the same way as normal immediate filing records described previously except that database consistency is maintained if multiple processors update the record.
- DASD locking
- Records that are to be held for exclusive use are fetched from DASD so that the external lock facility (XLF) can grant exclusive use to one processor. This is the default setting. Any record that will be changed should have this attribute. See z/TPF Concepts and Structures for more information about XLF.
- Processor locking
- A record that is used in a read-only capacity or is processor unique bypasses
the XLF when the record is located in VFA. The VFA copy is fetched and no
DASD I/O is performed. Attention: Do not consider this option unless extremely high performance is warranted. Because the XLF is bypassed, the data integrity of the record can be compromised.
- General data set record
- A special VFA candidacy condition exists for certain general data set (GDS) records. Index records that are associated with virtual storage access method (VSAM) data sets mounted to the z/TPF system are cached in VFA for performance reasons. VSAM record access requires an associated key lookup using an index data set; caching these index records eliminates the need for repeated accesses to DASD. The z/TPF system selects GDS record candidates internally; that is, you cannot use the ZRTDM command to select GDS record candidacy.