System Managed Buffering

System Managed Buffering (SMB) for VSAM datasets was introduced with DFSMS version 1.4 for KSDS files. This was enhanced with DFSMS 1.5 to include all VSAM files opened for NSR processing. Basically, the system decides how many buffers to use for data and index portions, and also whether to use NSR (best for sequential access) or LSR (best for OLTP acess). SMB will pick which buffering option is best for a specific job or application, and can even swap between them if necessary. SMB is better than the VSAM defaults, but not as good as third party buffering tools. This is because it is only invoked at file open time, whereas third party products will adjust the VSAM buffers as required over time.
The main restriction is that the data set must be in extended format, which means the data set must be SMS managed and use a data class that is defined with DSNTYPE=EXT.

Older releases of DFSMS could have a performance problem for DO processing as SMB allocated enough index buffers to hold the index at open time, but as the file grew, this buffer count was not enough. The only solution was to close and open the data set so that SMB recalculated the buffer count. Since DFSMS 1.11, SMB takes 20% for BUFNI, which is more than the previous implementation.
If you want to investigate how buffering is working, check out the SMF type 64 records that are generated when the file is closed. Also, look for an IEC161I message in the job or task output, as that will tell you which SMB buffering option was selected by VSAM for each opened data set.
The default for SMB is to allocate the buffer pool above the line, but you can change this if you wish.

   EADM Advert

Accelerate DB2 Write with zHyperWrite and "EADM™ by Improving DB2 Logs Volumes Response Time:

With DFSMS V2.1, you can specify ACCBIAS and RMODE31 values in SMS data classes

You use Record Access Bias to tell VSAM how many and which type of buffers to use during batch processing, when accessing VSAM EF files. The Parameters available are:

  • S - (System) specifies VSAM to use SMB, determining the buffer algorithms based on the ACB MACRF macro and storage class specification. If you use this, then make sure that MACFR has only one access type and that the storage class bias parameters are correctly set
  • U - (USER) tells VSAM to obtain buffers the same way as if without SMB. This is the default value.
  • DO - (Direct Optimised) Uses SMB with direct access optimization. SMB changes the buffering management to LSR (LRU) and allocates the adequate number of buffers for direct processing.
  • DW - (Direct Weight) the processing is mixed direct and sequential, but mostly direct access. More index buffers are allocated to support direct processing, but some buffers are reserved for data to help with sequential processing. The buffering management technique is changed to LSR (LRU).
  • SO - (Sequential Optimized) SMB will optimise buffer allocations for sequential processing, so more data buffers are allocated to support sequential access and fewer index buffers are allocated.
  • SW - (Sequential Weight) the processing is mixed direct and sequential, but mostly sequential access. SMB optimizes buffer handling for sequential processing by allocating more data buffers, but buffers are reserved for index to help direct access. SMB is even faster than NSR for sequential process.

If you specified direct optimization (DO), then you can further tune the way the buffers work with DD AMP parameters

  • SMBVSP overrides the default buffer space by specifying the amount of virtual storage to obtain for buffers when opening the data set. The buffer space is calculated assuming that 20% of the data records accounts for 80% of the accesses. The buffer space that is acquired is split across two LSR pools: One for the index and one for the data. You can use SMBVSP=nnK or SMBVSP=nnM. Without this parameter, the first DD statement that indicates SMB will get most of the virtual storage.
  • SMBHWT is a weighting number used to allocate hiperspace buffers based on a multiple of the number of address space virtual buffers that have been allocated. It can be an integer from 0 to 99. These buffers can be allocated for the base data component of a sphere. The default is 0, which means don't use hiperspace and IBM recommends that hiperspace is not used.
  • SMBDFR allows you to manage defered writes and can take the values 'Y' or 'N'. The defaults depend on the file share options, Y is the default for SHAREOPTIONS (1,3) and (2,3) while N is the default for SHAREOPTIONS (3,3), (4,3) and (x,4)

There are two ways to invoke SMB

  • via an SMS dataclass. The dataclass must be defined as
  • EXTENDED          REC ACC
    ADDRESSABILITY    BIAS
    -----(27)-----    -(39)--
    YES               SYSTEM

  • Via JCL, using
  • //ddname DD DSN=vsam.cluster.name,AMP=('ACCBIAS=SYSTEM'),DISP=SHR

Anything specified in the JCL will override the DataClass.

Other possible values for ACCBIAS are

  • SO
  • SW
  • DO
  • DW
  • USER

These terms are all explained above

RMODE31 Specifies whether for VSAM to allocate the buffers and control blocks in 31-bit addressable storage. You can use this field independently of SMB. With SMB, the default location is in 31-bit addressable storage (above the 16-megabyte line). Without SMB, the default is in 24-bit addressable storage (below the line). The following values can be specified for RMODE31 in data class:

  • All - All buffers and control blocks reside above the line.
  • BUFFER - Only buffers reside above the line.
  • CB - Only control blocks reside above the line.
  • NONE - Buffers and control blocks reside below the line.

You may see a couple of other options quoted, CO (create optimised) and CR (create recovery). These are selected by the system, and cannot be specified manually. They are used for initially loading a VSAM data set, CO is used with 'SPEED' and CR with 'RECOVERY'.
Three other 'AMP' JCL options are available to control how SMB uses buffers if ACCBIAS=DO is used. SMBVSP restricts the overall size of the buffers, SMBHWT will reserve hyperspace buffers, and SMBDFR can delay buffer writes until end-of-job, or until the buffer is full, whichever comes soonest. You specify the lot in an AMP statement as

AMP=('ACCBIAS=DO','SMBVSP=50M', 'SMBHWT=30','SMBDFR=Y')

These are just example numbers, you need to decide what is best for you. SMSVSP is nnK or nnM, SMBHWT is 0-99 and SMBDFR is Y or N

You can specify the SMB buffer processing as SO/SW/DO/DW as above, or simply use SYSTEM and let the system pick it out. It decides this based on the access method. SMB will use NSR buffers, unless DO is specified. It then changes the buffering internally to LSR. However, if SMB cannot get enough LSR buffers, it will change the buffering to DW.

The pecking order which decides if SMB will be invoked is JCL specifications, then the data class Record-Access-Bias parameter, then the MACRF values. That is, whatever is specified in the JCL will always take preference.

back to top