Enscribe Programmer's Guide

record, a disk write by another process may have occurred between your read call and the
CONTROL 27 call.
Because the automatic resending of a CONTROL 27 request could be queued behind a disk write
request by another process (thus missing it), the file open through which you issue the CONTROL
27 call should have a sync depth of 0. In such a case, you should treat path errors (200-211) and
network errors (240-249) as successful completions in that you then immediately check the critical
record(s) for new data.
Using Cache Buffering or Sequential Block Buffering
The Enscribe product provides two buffer management options, cache buffering and sequential
block buffering, that you can sometimes use to make I/O operations more efficient.
Cache Buffering
The cache, or buffer pool, is an area of main memory reserved for buffering blocks read from disk.
You use the PUP SETCACHE command to specify the cache size.
When a process reads a record, the Enscribe software first checks the cache for the block that
contains the record. If that block is already in the cache, the record is transferred from the cache
to the application process. If the cache does not contain the block, the block is read from the disk
into the cache and then the requested record is transferred to the application process.
If no space is available in the cache when a block must be read in, some other block must be
selected to be overlaid. A choice of three different cache access types is available: sequential
access, random access, and system managed.
When a process writes a record, what happens differs according to the options selected when the
file was opened. If the buffered cache feature is not used, the cache block that contains the record
is modified, and then immediately written to disk. If the block to be modified is not in the cache,
it is first read from the disk. The modified block remains in cache, however, until the buffer space
is needed for overlay; this is called write-through cache.
You can open a file with buffered cache so that the cache contents are written to disk, or flushed,
less frequently. If several data changes occur to records in the same block in the cache, transaction
time is faster because less I/O to the disk is required. Database changes, however, do not get into
the actual disk file until the cache block is flushed for some reason. These situations cause a block
to be flushed:
• Any opener closes the file.
• The SETMODE procedure forces flushing.
• TMF forces flushing.
• Space is needed for a new block to be read into cache. The disk process selects the least
recently used data block and flushes it to make room for the new one.
• The cache configuration is changed.
• The buffer size of an unstructured file is changed by a SETMODE procedure call, causing all
cache buffers for that file to be flushed.
• The DISK_REFRESH_ procedure, or equivalent command, is used on the file.
• When the disk process has been idle for a sufficient period of time, it uses the free time to
flush modified cache buffers until it receives a user request.
Any file can be either buffered or write-through; the defaults are buffered for audited files and
write-through for non audited files.
Write-through cache is the default for nonaudited files, because a system failure or unplanned disk
process takeover (with a sync-depth of 0) could cause the loss of buffered updates and an
application might not detect or handle such a loss properly. Such a loss of buffered updates would
54 General File Creation and Access Information