Enscribe Programmer's Guide

specification in the buffer. Thus the benefits and limitations of sequential block buffering apply to
the alternate-key file I/O, not to the primary file I/O.
Shared File Access
For sequential block buffering, the file usually should be opened with protected or exclusive access.
Combining sequential block buffering and shared access is allowed, but be aware that this
combination can cause concurrency problems.
If another process is updating data copied into the block buffer, those updates might not be seen
by the process using the buffer. For example, assume process A is reading a buffered block of
data while process B inserts a new record into that block on the disk. The new record will not be
in the buffer that process A is reading. Although process A's user might expect to see the record
that process B inserted, that record will not be in the buffer unless process A reads that block again.
Sharing Buffer Space
You can have two or more files share the same buffer space by specifying identical
sequential-block-buffer parameters in FILE_OPEN_. This can result in significant memory consumption
savings in some applications.
When using this feature, however, be certain that the first file opened either has the largest block
size or is opened with enough buffer space to accommodate the largest file. If a file tries to share
a buffer that was already created with a smaller block size, the open operation succeeds but returns
an indication with warning 5 (failure to provide sequential buffering) and block buffering is not
used.
A shared buffer can be useful when reading whole blocks of data from several files, but it would
be inefficient when reading a single record or switching between files on successive reads, because
the buffer is refilled each time a new file or random record is read.
If you omit the sequential-block-buffer parameter when opening a file on an HP NonStop™ Operating
system, the file cannot share a buffer.
Specifying the Appropriate Disk File ACCESSTYPE Parameter
A parameter called ACCESSTYPE is associated with each disk file. This parameter in effect tells
the disk process how to use its buffer and cache space when reading from and writing to the
associated file. You use SETMODE 91 calls to examine or set ACCESSTYPE.
Choosing the most appropriate ACCESSTYPE for each of an application's files can increase the
efficiency with which the disk process carries out its tasks. The various access modes are:
• Random access. When you specify random access, the disk process employs a least recently
used (LRU) approach to reusing cache space. This practice tends to keep frequently used
blocks in cache memory instead of reading them in from the disk every time they are needed.
• Sequential access. When you specify sequential access, the disk process uses essentially the
same LRU algorithm that it does for random access but does so in such a way that the least
recently used data blocks are removed from the cache sooner. With sequential access, the
least recently used data block survives in cache approximately half as long as it would for
random access. This practice prevents cache memory from being filled with data blocks that
you probably do not need again.
• There are two cases that tend to call for this type of access: one being the truly sequential
case and the other being the case where you are accessing a very large file randomly.
• System-managed access. When you specify system-managed access, the disk process decides
whether you are accessing the file randomly or sequentially based upon your previous usage
and optimizes its behavior accordingly. This is the default access type.
• Direct I/O. When you specify direct I/O access, the disk process bypasses cache memory
completely if the file has been opened for write-through, unstructured access in either exclusive
read/write or protected read-only mode. This type of access might be desirable, for example,
File Access 57