Re: Speed in Reading

On 07-Jun-2010 15:37, Mark S. Waterbury wrote:

Well, since you asked ...

The "event" that is "triggered" is to issue the MI instruction
SETACCST (Set Access State) ... with the "bring" option bit set
in the template. See here for more details:

http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/rzatk/SETACST.htm

There is also the QDBBRCDS API -- to "bring" a set of records
into real main storage" -- see here:

http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/apis/qdbbrcds.htm

Perhaps someone with more "internals" knowledge than I (like
Bruce Vining or Chuck Pence) could comment on the "pros and cons"
of using QDBBRCDS versus SETOBJACC versus the MI SETACCST
instruction.

The SETOBJACC command synchronously /brings/ data into the specified memory pool, the _entire dataspace_, and optionally the dataspace index. The command also supports specification of an LF in order to access all of the underlying data member(s) and its access path(s). Good for each of random, direct, and sequential access; especially if processing the majority of the rows or index entries. Ideally used only when the assigned pool is not shared; dedicated only to a known amount of physical storage, for which the pool configuration accommodates the full amount.

The database API asynchronously /brings/ into the memory pool assigned to the requesting job, only the physical data pages for the specified RRNs. The API allows specifying only a specific database physical file member. If you know you are going to process only the rows appended at the end of the dataspace for example, then use this API to bring that specific portion of the dataspace\data into memory; done in the hope that the /bring/ completes before actual physical data access, to avoid faulting the data into memory. Best for use with direct or sequential access, where the former implies which RRN to be accessed is\are known, whereas the latter implies either which or /near which/ RRNs are of interest to be accessed is either known or can be predicted.

I do not recall the implementation of, nor the requirements for origin of, the Bring Database Records (QDBBRCDS) API. And I never had to provide a fix for that code :-) such that I may have had to learn more. The documentation is sorely lacking if not also possibly misleading. Minimally, for lack of mention of deleted records and a definition of /invalid/ which may or may not include a row which is the RRN of a deleted record. For example: "Invalid relative record numbers in the array are ignored." but "All relative record numbers prior to the invalid relative record number in the array are processed." If invalid RRN are ignored, then why would only *prior* values /in the array/ are processed? As if the RRNs in the array could only be specified ascending [not stated] and only those RRN exceeding the highest valid RRN are invalid.? Or do they mean any /lower value RRNs/ will still be processed?

Regards, Chuck