COFVLFxx (virtual lookaside facility parameters)

The virtual lookaside facility (VLF) enables an authorized program to store named objects in virtual storage managed by VLF and to retrieve these objects by name on behalf of users in multiple address spaces. VLF is designed primarily to improve performance by retrieving frequently used objects from virtual storage rather than performing repetitive I/O operations from DASD.

Certain IBM® products or components such as LLA, TSO/E, CAS, and RACF® use VLF as an alternate way to access data. Since VLF uses virtual storage for its data space there are performance considerations each installation must weigh when planning for the resources required by VLF.

For a description of VLF, see z/OS MVS Programming: Authorized Assembler Services Guide.

A VLF class is a group of related objects made available to users of an application or component. To get the most benefit from using VLF, consider its use for objects that are:
  • Used frequently
  • Changed infrequently
  • Used by multiple end users concurrently.
To activate a class of VLF objects, VLF requires that a CLASS statement describing that group of objects be present in the active COFVLFxx parmlib member (the member named on the START command used for VLF).

For example, library lookaside (LLA) uses the class of VLF objects named CSVLLA. If the CLASS statement for CSVLLA is not included in the active COFVLFxx parmlib member, LLA cannot use VLF, and many of the performance and operational benefits of LLA will not be available.

IBM supplies a default VLF parmlib member (COFVLF00) that contains CLASS statements for the VLF classes used by IBM-supplied products. You might need to tailor some of these CLASS statements to meet your installation's needs. In addition, your installation can write applications that use VLF, and you must include the CLASS statements for those applications.

There are three items VLF requires for each VLF class used. They are:

  1. The name of the class, specified on the required NAME parameter.

    IBM supplies the names of the classes it uses. These names start with the letters A-I.

  2. The maximum amount of virtual storage that your installation wants VLF to use for the objects in the class.

    Unless you supply this value on the optional MAXVIRT parameter of the CLASS statement, VLF will use a default value. Generally, the information about the IBM product that uses the VLF class provides some guidance about how to determine an appropriate value for MAXVIRT.

    For any given class, the goal is usually to provide an amount of virtual storage large enough to hold a working set of objects—those objects that are used frequently enough to justify keeping them in virtual storage to avoid DASD retrieval.

    When you specify the MAXVIRT value, ensure that it is large enough to hold most or all of the frequently-used objects in a VLF class. An excessively small value tends to cause thrashing of the data in that VLF class, while an excessively large MAXVIRT value tends to increase the consumption of auxiliary storage because infrequently-used data is paged out, rather than discarded. Specifying MAXVIRT allows you to limit the maximum amount of auxiliary storage that could be used to back the VLF virtual storage that is holding the objects in the class.

    The MAXVIRT value does not represent the exact amount of virtual storage that can be used to store objects. A small percentage of the storage (about 10 percent) is used for control information, and, in most cases, VLF begins to trim (discard) least recently used objects when the amount of virtual storage used for the class approaches 90 percent of the MAXVIRT value. Therefore, allow some excess.

  3. A list of the major names that represent the eligible sources of data for objects in the VLF class.

    How you specify the major names depends on whether the VLF class is a PDS class or a non-PDS class.

    For a PDS class, each major name identifies a unique partitioned data set and consists of a PDS name concatenated to the volume serial number. For a PDS class, use the EDSN and VOL parameters on the CLASS statement to define the major names.

    For a non-PDS class, the major name does not correspond to a partitioned data set. To specify the eligible major names for the class, use the EMAJ parameter on the CLASS statement. For an IBM-supplied class, use the product information to determine if anything other than the name(s) specified in the IBM-supplied default COFVLFxx member are eligible.

In addition to the class and major name, VLF also needs a minor name to identify a unique data object, but the minor names do not come from the COFVLFxx parmlib member.

In using the VLF naming structure, consider the TSO/E use of VLF to manage objects in the IKJEXEC class.
  • Each TSO user can have a SYSPROC DDNAME with a different concatenation. When TSO/E identifies the user to VLF, it specifies DDNAME(SYSPROC). VLF then determines the major names (volume serial number and PDS name combinations) that make up the individual major name search order for that user. VLF returns a unique user token (UTOKEN) for that user.
  • When that user requests a specific object (such as a CLIST named COPY) from the IKJEXEC class, the user token implicitly specifies the major name search order. When VLF returns the COPY object to the user, the object represents the first object with that minor name to be found in the major name search order for that user.

COFVLFxx parmlib members can be concatenated. When they are concatenated, a class definition can span parmlib members.