PREFETCH may reduce run-time resources for some applications, but cause additional expense for others. It is important to know when PREFETCH may be enabled and what the defaults are, in order to ensure that programs run as efficiently as possible.
What considerations apply when considering using PREFETCH?
Release: All supported releases.
Component: IDMS/DB
When will Prefetch be invoked?
There are a number of considerations regarding PREFETCH and when it is used. First, it is not enough that jobs do not code the PREFETCH=ON SYSIDMS parameter; unless they specify PREFETCH=OFF then Prefetch will be enabled in certain circumstances. Specifically, for batch jobs that do not have PREFETCH=OFF, PREFETCH is enabled by default in these situations:
To determine whether PREFETCH is disabled in the CV, use the DCMT DISPLAY BUFFER command. If the CV SYSIDMS specifies PREFETCH=OFF, then any open buffer should show PREFETCH NOT ALLOWED in the output from a DCMT DISPLAY BUFFER. If it does not show this, then it is possible for jobs running through the CV to use PREFETCH when the buffer definitions meet the conditions outlined above.
When should I want to use Prefetch
When Prefetch runs, it does a track read, as opposed to a page read. So the number of database pages in a track will be a big factor in the impact that using Prefetch will have against a particular area. If you issue a DCMT DISPLAY AREA <area-name>, this will display both the area and the file. On the second line of the File display, is the 'Pages per Track'. For PREFETCH to have a positive impact when accessing a particular database area, this should be at least 3.
Trying to fine-tune performance is a very specific task & will vary from job to job, depending on the type access it does and the structure of the database areas being accessed. The best way to verify whether PREFETCH should be specified for a particular task is to run various tests and compare the results.
First, run the job with QSAM. Add to the DD statement for the particular DB area being accessed, the parm DCB=BUFNO=255; or add to the SYSIDMS the parm QSAMBUF#=255. Either one of these tells QSAM to utilize 255 buffers for its I/O. QSAM is an IBM product that runs outside the IDMS address space. It intercepts the I/O request from IDMS and issues its own I/O READ into its buffers. Then it transfers the page to IDMS. While IDMS is processing, QSAM reads the next page. The DCB= parm tells QSAM to use 255 buffers (the max).
Then run a test using Prefetch. To the SYSIDMS add PREFETCH=ON to ensure that Prefetch is actually on. Also add to the SYSIDMS FILE_BUF=ddname=1000. The ddname is the DD-Name of the database area being accessed – the same one you specified the QSAM buffers for in the first test. This will add 1000 buffer pages to the buffer pool, which should allow Prefetch to run. For both the QSAM and the Prefetch runs, add a SYSIDMS parm BUFFERSTAT. Also make sure there is a SYSLST dd statement. The BUFFERSTAT parm will produce a small report about the Buffer pools and the related I/O, and send it to SYSLST.
Finally, run the job again with both the QSAM and Prefetch parms. Specify the BUFFERSTAT SYSIDMS parm as noted before.
Review the Bufferstat reports for all test jobs you’ve run, and compare them. Also compare the elapsed times. This will give you an indication of the most efficient parms to use for this particular job.
Additional information about Prefetch can be found at Using Chained Reads .