DMSII Buffer Management is still being debated and misunderstood to this day. This goes way back to the beginning of DMSII and the hardware environment of the time. Past systems compared to today's systems were much smaller and had very limited resources. System memory was measured in thousands of words as opposed today's systems that measure memory in millions of words.
To begin to understand buffer management we must look at the factors that make up and control DMSII memory management. We will also need to know the interaction among these factors.
In the early days of DMSII, most of the memory management and buffer management was done by the database administrator based upon their knowledge of the data usage. Because most of the processing was batch processing it was easier to predict data usage. Today's systems tend to be on-line, real-time based, and data usage is much more dynamic.
The theory behind buffers is tied to system technology. Basically, memory is high speed data storage. The system can access data in memory much faster than attached storage such as disk drives and solid-state storage devices. In a perfect world the entire database would be contained in memory, but due to cost limitations we have not reached that point yet. The compromise is to keep the most-used data in memory. This is where DMSII Buffer Management comes into play.
What is a buffer? A buffer is a block of data from a structure. Buffers are variable in size based upon the blocksize of the structure associated with the buffer. A structure can have anywhere from zero to multiple buffers. This is determined either by the database administrator using manual options to control it, or it can optionally be controlled and managed by DMSII. In today's dynamic database environment, I believe that buffer management can best be done by DMSII software.
Buffer management consists of two categories, manual buffer management and DMSII buffer management. With manual buffer management, control of buffers is done by the DBA. DMSII buffer management is done by the DMSII software. The DBA can adjust the factors that control it, but DMSII software does the work.
DMSII buffer management (as opposed to manual buffer management) is initiated by setting OVERLAYGOAL to a value other than zero. Doing this will cause DMSII to take control of the buffers. This is fine-tuned by adjusting ALLOWEDCORE, OVERLAYGOAL and buffer settings.
The ALLOWEDCORE setting determines how much of the system memory will be used for the buffers of the database. You need to be aware that ALLOWEDCORE is saved memory. Saved memory is memory that can't be overlayed by the system. So, you want to set the amount of ALLOWEDCORE for each database considering which databases will be running at the same time. It should be assigned based upon the size (in structures) and importance of the database. I would advise that you keep the total of all running databases' ALLOWEDCORE under 80% of total system memory.
OVERLAYGOAL should be set. However, the default value for OVERLAYGOAL is 1, and you should not use this value. You should use a value less than 1, particularly with large ALLOWEDCORE. OVERLAYGOAL is the percentage of ALLOWEDCORE that will be overlayed every minute. Back when OVERLAYGOAL was first defined, ALLOWEDCORE settings were much smaller than today. But with today's ALLOWEDCORE settings an OVERLAYGOAL of 1 (1% of ALLOWEDCORE) would cause too many forced overlays of the buffers. Usually OVERLAYGOAL should be set to 0.001 or less, depending on the amount of ALLOWEDCORE.
We have covered OVERLAYGOAL and ALLOWEDCORE. The last thing we need to discuss is buffer settings. Buffer settings can be set globally or on an individual structure level. Buffer settings can be set in either the DASDL or can be set using VDBS commands. Buffer settings have three components, the system, random and serial settings. The settings take the form of:
BUFFERS = <system> + <random> PER USER OR <serial> PER SERIAL USER
When using DMSII buffer management, the random setting doesn't really matter, I usually just set it to 1. The serial setting does need to be set to a value of 2 or more, because if it is less than 2, readahead processing is disabled. I generally set it to 2. The system buffer setting is important, because there is a default limit of 512. If the system value is not set to a value greater than 512, then the maximum buffers that will be used for the structure is 512. With large ALLOWEDCORE settings, the number of buffers becomes a limiting factor for a structure.
If you look at in-use buffer statistics and see several buffers at 512, it indicates system buffers have not been set. If you have set a system buffer to 10,000 and you see the structure buffers in use at 10,000, it indicates the structure could use more buffers.
Setting system buffers to a number higher than needed doesn't force the structure to use the number, the system will only allocate the buffers needed by the structure. If for some reason you want to limit a structure you can do it with system buffers.
I believe in setting the system buffers high for all structures to let DMSII manage them and use what is needed.
In conclusion, I believe in letting DMSII manage the buffers. DMSII can do a much better job of managing ALLOWEDCORE. Set ALLOWEDCORE as high as you can, taking into consideration total system memory and other databases that will be in use. Set OVERLAYGOAL and let DMSII do the work. Set system buffers high enough that structures are not being limited.