VSAM options
Several types of options can be chosen for databases that use VSAM.
Specifying options such as free space for the ESDS data set, logical record size, and CI size are discussed in the other topics in this section. This topic describes these optional functions:
- Functions specified in the OPTIONS control statement when IMS is initialized.
- Functions specified in the POOLID, VSRBF, and DBD control statements when IMS is initialized.
- Functions specified in the Access Method Services DEFINE CLUSTER command when a data set is defined.
Optional functions specified in the OPTIONS control statement
Several options exist that can be chosen during IMS system initialization for databases using VSAM. These options are specified in the OPTIONS control statement. In a batch system, the options you specify are put in the data set with the DDNAME DFSVSAMP. In an online system, they are put in the IMS.PROCLIB data set with the member name DFSVSMnn. Your choice of VSAM options can affect performance, use of space in the database, and recovery. This topic describes each option and the implications of using it.
Using background write (BGWRT parameter)
When an application program issues a call requiring that data be read from the database, the data is read into a buffer. If the buffer the data is to be read into contains altered data, the altered data must be written back to the database before the buffer can be used. If the data was not written back to the database, the data would be lost (overlaid) when new data was read into the buffer. Then there would be no way to update the database.
For these reasons, when an application program needs data read into a buffer and the buffer contains altered data, the application program waits while the buffer is written to the database. This waiting time decreases performance. The application program is ready to do processing, but the buffer is not available for use. Background write is a function you can choose in the OPTIONS statement that reduces the amount of wait time lost for this reason.
To understand how background write works, you need to know something about how buffers are used in a subpool. You specify the number of buffers and their size. All buffers of the same size are in the same subpool. Buffers in a subpool are on a use chain, that is, they are chained together in the order in which they have been most or least recently used. The most recently used buffers are at the top of the use chain; least recently used buffers are at the bottom.
When a buffer is needed, the VSAM buffer manager selects the buffer at the bottom of the use chain. The buffer at the bottom of the use chain is selected, because buffers that have not been used recently are less likely to contain data that will be used again. If the buffer the VSAM buffer handler picks contains altered data, the data is written to the database before the buffer is used. It is during this step that the application program is waiting.
Background write solves the following problem: when the VSAM buffer manager gets a buffer in any subpool, it looks (when background write is used) at the next buffer on the use chain. The next buffer on the use chain will be used next. If the buffer contains altered data, IMS is notified so background write will be invoked. Background write has VSAM write data to the database from some percentage of the buffers at the bottom of the use chain. VSAM does this for all subpools. The data that is written to the database still remains in the buffers so the application program can still use any data in the buffers.
Background write is a very useful function when processing is done sequentially, but it is not as important to use in online systems as in batch. This is because, in online environments, IMS automatically writes buffers to the database at sync points.
To use background write, specify BGWRT=YES,n on the OPTIONS statement, where n is the percentage of buffers in each subpool to be written to the database. If you do not code the BGWRT= parameter, the default is BGWRT=YES and the default percentage is 34%. If an application program continually uses buffers but does not reexamine the data in them, you can make n 99%. Then, a buffer will normally be available when it is needed.
CICS® does not support this function.
Choosing an insert strategy (INSERT parameter)
Get free
space in a CI in a KSDS is by specifying it in the DEFINE
CLUSTER
command. Free space for a KSDS cannot be specified
using the FRSPC= keyword in the DBD.
To specify free space
in the DEFINE CLUSTER
command, you must decide:
- Whether free space you have specified is preserved or used when more than one root segment is inserted at the same time into the KSDS.
- Whether to split the CI at the point where the root is inserted, or midway in the CI, when a root that causes a CI split is inserted.
These choices are specified in the INSERT= parameter in the OPTIONS statement. INSERT=SEQ preserves the free space and splits the CI at the point where the root is inserted. INSERT=SKP does not preserve the free space and splits the CI midway in the CI. In most cases, specify INSERT=SEQ so free space will be available in the future when you insert root segments. Your application determines which choice gives the best performance.
If you do not specify the INSERT= parameter, the default is INSERT=SKP.
Using the IMS trace parameters
The IMS trace parameters trace information that has proven valuable in solving problems in the specific area of the trace. All traces share sequencing numbers so that a general picture of the IMS environment can be obtained by looking at all the traces.
IMS DL/I, LOCK and retrieve traces are on by default, except in batch regions, where they are off by default. All other trace types are off by default.
The
traces can be turned on at IMS initialization
time. They can also be started or stopped by the /TRACE
command
during IMS execution. Output
from long-running traces can be saved on the system log if requested.
Determining which dump option to use (DUMP parameter)
The dump option is a serviceability aid that has no impact on performance. It merely describes the type of abend to take place if an abend occurs in the buffer handler (an internal component). If DUMP=YES is specified, the control region will abend when there is an abend in the buffer handler.
Deciding whether to fix VSAM database buffers and IOBs in storage (VSAMFIX parameter)
Each VSAM subpool contains buffers and input/output control blocks (IOBs). Performance is generally improved if these buffers and IOBs are fixed in storage. Then, page faults do not occur. A page fault occurs when an instruction references a page (a specific piece of storage) that is not in real storage.
You can specify whether buffers and IOBs are fixed in storage in the VSAMFIX= parameter of the OPTIONS statement. If you have buffers or IOBs fixed, they are fixed in all subpools. If you do not code the VSAMFIX= parameter, the default is that buffers and IOBs are not fixed.
This parameter can be used in a CICS environment if the buffers were specified by IMS.
Using local shared resources (VSAMPLS parameter)
Specifying VSAMPLS=LOCL in the OPTIONS statement is for local shared resources (LSR). When you specify VSAMPLS=LOCL, VSAM control blocks and subpools are put in the IMS control region. VSAMPLS=LOCL is the only valid operand and the default.