In ADM PFA caching, systems support controls the creation of cache areas and the allocation of selected data areas (a cache area is always a subarea of a cache that represents a separate administration unit). Systems support can use /START-DAB-CACHING to create independent cache areas and thus to separate selected data belonging to different applications. A cache area can also be created for entire volumes. You will find a detailed description of this in the manual “DAB” [5 (Related publications)].
The term AutoDAB refers to a variant of DAB caching. It involves automatic and intelligent procedures which, on the one hand, greatly reduce the work of systems support when administering the caching and, on the other, allow the efficiency of the DAB caching to be further increased.
A DAB cache area can be set up as either an “automatic” or a “non-automatic” cache area.
Any of the following three settings is possible when using the cache buffer:
The authorized user can specify which files are to use the cache area created in which cache mode.
Systems support can specify that all user files of a pubset are to use the cache area.
Systems support can create an automatic cache area in which the optimum selection of the files to be supported occurs automatically. This selection is permanently monitored and, if necessary, corrected. AutoDAB enables entire pubsets to be covered by a cache area.
DAB manages each cache area in the form of so-called cache segments whose default size is 32 KB for automatic cache areas. The default size of a cache segment in automatic cache areas is 32 KB. For non-automatic cache areas it can also be specified by systems support (4 KB, 8 KB, 16 KB or 32 KB). Automatic caching must be stopped during the modification.
The first time an area (file) supported by DAB is read-accessed, DAB reads from the storage system page-chained, adjacent data blocks, the number of which depends on the set cache segment size.
Spatial locality
In read accesses with good spatial locality (particularly for sequential accesses), large segments (= 32 KB) allow such a high throughput of I/O jobs that in this case, there are a large number of read hits and the accesses to the storage system are reduced to a minimum.
In read accesses with low spatial locality (random access, the most frequently used access type in database mode) it is advisable to select small segments (= 4 KB).
AutoDAB recognizes good locality and, when it finds it, automatically performs a prefetch (even if a smaller cache segment was set).
Chronological locality
The blocks read into the cache remain there until DAB is terminated or this memory area is used for another cache segment.
Preemptions are managed on the LRU (least recently used) principle, which means that a high read hit rate can be achieved given good chronological locality of the accesses even with a relatively small cache area.
For performance-critical applications whose read accesses have low chronological locality, DAB offers the possibility of resident buffering.
In the case of a read/write (or write) cache, write jobs are always entered in the cache directly, regardless of whether or not the data block is already in the cache. As far as the application is concerned, the output operation is completed as soon as the data is written to the cache. DAB saves the data on the storage system later.
It must be noted that DAB creates the system buffer in main memory on a resident basis (i.e. main memory must be large enough).
Systems support uses the following commands to control the use of ADM PFA caching with DAB:
Command | Function |
| Creates and assigns attributes to cache areas |
| Outputs information on the current DAB configuration and access counters (hit rates) |
| Saves cache areas on disk and deletes them |
| Dynamically modifies parameters of a DAB cache area |
| Deletes a DAB cache area without backing up the write data |
Recommendations on use
General use of AutoDAB
The selection of the data set to be buffered and the setting of the prefetch factor should occur through the automatic caching. It is therefore recommended that you operate the performance-critical volumes or pubsets with AutoDAB.
As a rule, the following procedure is simple and effective:
Determine all performance-critical applications
Determine all volumes/pubsets that are accessed by these applications
Combine all these volumes/pubsets to form an automatic ADM PFA cache area (useful if nothing is known of the access frequency of individual pubsets or Define an automatic PFA cache area for each individual pubset (see also section "User PFA caching").
Defining the size of the cache area
The size of the cache area should be at least 1% of the size of the data set to be supported (files processed in parallel). With predominantly sequential processing, this value can be lower, while with predominantly random processing it may be too small. If the cache size is not sufficient, this will be reported by AutoDAB as a console message.
Speeding up of all write accesses:
Regardless of the locality, when a read/write (or write) cache is used, DAB speeds up all write accesses as long as there are free buffers available.
As a result, short-term peak loads can be dealt with and fast file access times achieved. However, since DAB has to save on the storage system the write data buffered in the cache, in the case of write applications the input/output system can only be relieved when the locality of the accesses is sufficiently high.Home pubset
The home pubset cannot be buffered in the main memory. Although this is possible with ADM PFA caching, it should only happen with a pure read cache.
SM pubsets
The data of an SM pubset cannot be buffered in a DAB cache medium with ADM PFA caching (since the storage location, i.e. the volume set, of the file can be changed dynamically).
Database pubsets
With pure database pubsets it may be possible to improve the “chronological locality” by selecting a smaller segment size: e.g. 8 KB instead of the default value 32 KB (/START-DAB-CACHING, parameter CACHE-SEGMENT-SIZE).
In the case of applications which cause a higher I/O rate additional disks should be used to increase the throughput. (The use of DAB for write IOs is not always recommended.)
You will find more detailed information on using DAB in the “DAB” manual [5 (Related publications)].