- VSAM structures
- VSAM commands
- Performance tuning
- JCL Buffers
- LSR Buffers
- System Buffers
- VSAM parameters
- IAM, a VSAM alternative
- VSAM Recovery
- VSAM RLS, DFSMStvs
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. 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 neessary. 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.
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:
There are two ways to invoke SMB
EXTENDED REC ACC
//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
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:
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
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
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.