The following guidelines and restrictions relate to processing with each technique.

Direct Optimized (DO) Guidelines. DO could result in a requirement for the most additional processor virtual storage. This results in the creation of a local shared resources (LSR) pool for each data set opened with this technique in a single application program. The size of the data set is a major factor in the processor virtual storage requirement for buffering. The size of the pool is based on the actual data set size at the time the pool is created. This means that the processor virtual storage requirement increases with each OPEN after records have been added and the data set has been extended beyond its previous size.

For each data set, a separate pool is built for both data and index components if applicable. There is no capability to share a single pool by multiple data sets. However, DSN sharing and DDN sharing is supported. The index pool is sized to accommodate all records in the index component. The data pool is sized to accommodate approximately 20% of the user records in the data set. As discussed previously, this size can change based on data set growth. A maximum pool size for the data component is identified. These buffers are acquired above the 16 MB line unless overridden by the use of the RMODE31 parameter.

You can use the SMBVSP parameter to restrict the size of the pool that is built for the data component or to expand the size of the pool for the index records. The SMBHWT parameter can be used to provide buffering in Hiperspace in combination with virtual buffers for the data component. The value of this parameter is used as a multiplier of the virtual buffer space for Hiperspace buffers. This can reduce the size required for an application region, but does have implications related to processor cycle requirements. That is, all application requests must orient to a virtual buffer address. If the required data is in a Hiperspace buffer, the data must be moved to a virtual buffer after “stealing” a virtual buffer and moving that buffer to a least recently used (LRU) Hiperspace buffer.

If the optimum amount of storage required for this option is not available, SMB will reduce the number of buffers and retry the request. For data, SMB will make two attempts, with a reduced amount and a minimum amount. For an index, SMB reduces the amount of storage only once, to minimum amount. If all attempts fail, the DW technique is used. The system issues an IEC161I message to advise that this has happened. In addition, SMF type-64 records indicate whether a reduced or minimum amount of resource is being used for a data pool and whether DW is used. For more information, see z/OS MVS System Management Facilities (SMF).

Restrictions on the Use of Direct Optimized (DO). The Direct Optimized (DO) technique is elected if the ACB only specifies the MACRF=(DIR) option for accessing the data set. If either SEQ|SKP are specified, either in combination with DIR or independently, DO is not selected. The selection can be overridden by the user specification of ACCBIAS=DO on the AMP=parameter of the associated DD statement.

There are some restrictions for the use of the Direct Optimized (DO) technique:

1. The application must position the data set to the beginning for any sequential processing. This assumes the first retrieval will be set to that point of the data set.
2. Applications that use multiple strings can hang if the position is held while other requests process. An example of this is an application that has one request doing sequential GETs while another request does PUTs.

Sequential Optimized (SO) Guidelines. This technique provides the most efficient buffers for sequential application processing such as data set backup. The size of the data set is not a factor in the processor virtual storage that is required for buffering. The buffering implementation (NSR) specified by the application will not be changed for this technique. Approximately 500K of processor virtual storage for buffers, defaulted to above 16 MB, is required for this technique.

Direct Weighted (DW) Guidelines. This technique is applicable for applications in which the requests to the records in a VSAM data set are random for the majority of the accesses. In addition, it might also give some sequential performance improvement above VSAM defaults.

The size of the data set is a minor factor in the storage that is required for buffering. This technique does not change the buffering implementation that the application specified (NSR). This technique requires approximately 100K of processor storage for buffers, with a default of 16 MB.

Sequential Weighted (SW) Guidelines. This technique is applicable for applications where the requests to the records in a VSAM data set are sequential for the majority of the accesses. In addition, this technique might give some direct performance improvement over VSAM defaults.

The size of the data set is a minor factor in the amount of processor virtual storage that buffering requires. This technique does not change the buffering implementation that the application specified (NSR). This technique requires approximately 100K of processor virtual storage for buffers, with the default above 16 MB.

Create Optimized (CO) Guidelines. This is the most efficient technique, as far as physical I/Os to the data component, for loading a VSAM data set. It only applies when the data set is in initial load status and when defined with the SPEED option. The system invokes it internally, with no user control other than the specification of RECORD ACCESS BIAS in the data class or an AMP=(ACCBIAS=) value of SYSTEM.

The size of the data set is not a factor in the amount of storage that buffering requires. This technique does not change the buffering implementation that the application specified (NSR). This technique requires a maximum of approximately 2 MB of processor virtual storage for buffers, with the default above 16 MB.

Create Recovery Optimized (CR) Guidelines. The system uses this technique when a data set defined with the RECOVERY option is in initial load status. The system invokes CR internally, with no user control other than the specification of RECORD ACCESS BIAS in the data class or an AMP=(ACCBIAS=) value of SYSTEM.

The size of the data set is not a factor in the amount of storage that buffering requires. This technique does not change the buffering implementation that the application specified (NSR). This technique requires a maximum of approximately 1 MB of processor virtual storage for buffers, with the default above 16 MB.

To determine the final SMB processing technique and additional resource-handling information related to SMB, examine SMF type 64 records. This is mainly for diagnostic purposes because SMF type 64 records are gathered during the CLOSE processing of a data set. For more information on SMF records, see z/OS MVS System Management Facilities (SMF).