Re: Speed in Reading

On 08-Jun-2010 12:18, Vern Hamberg wrote:

From a cursory glance at the docs for QDBBRCDS, and never having
used it, this seems a reasonable approach. I have some thoughts
about how it'd work.

1. Being an asynchronous bring, as Chuck pointed out, the records
are brought into main memory independent of your job.
2. Depending on how much CPU processing you do per record, the
recordsmay or may not arrive before you read them.
3. The bring stops, apparently, with no indication it has done
so, when an "invalid RRN" is found in your array. Chuck wondered
if that is a deleted record - not clear.

<<SNIP>>

I was at least in part being somewhat facetious while berating the documentation for lack of detail. I am almost positive that the term /invalid RRN/ means to imply only a numeric value which is larger than /the last physical row/ in the dataspace. Each specified RRN value would simply be used in a calculation to determine the page(s) within the data segments on which the physical row data resides\spans. Since a deleted record can be positioned-to using an RRN, and then updated, that pretty-much makes that the RRN of a deleted record a /valid RRN/.

As to the meaning of the /All RRN prior to/, I am still unsure. The quoted doc:

"If an invalid relative record number is specified,
it is tolerated and no error is returned.
All relative record numbers prior to the invalid
relative record number in the array are processed.
Invalid relative record numbers in the array are
ignored."

The expressions "tolerated and no error" seems synonymous with "are ignored". So it seems utterly ridiculous that the last sentence was an addendum for v5r4; i.e. seems redundant, and without providing _any_ clarification to the prior two sentences.

Does the explicit statement that /all prior RRN/ will be processed imply that /all later RRN/ will *not* be processed? Or was the new sentence meant in some way to imply later RRN values would still be processed? If that worthless update was not a side effect of Chinglish... well even if it were, that documentation just sickens me. So much so, I just clicked the _*Send Feedback*_ link to submit an online Reader Comment Card against that doc.

I would hope that all entries in the array are /processed/ regardless of any\all /invalid RRN/ values. I suspect that only RRN values that are too large are considered /invalid RRN/ values, and only those array entries will be ignored by the API; that any invalid RRN in the array would not stop processing of any remaining entries. FWiW: Any value for an RRN value in the array would be considered /too large/ whenever the algorithm to calculate the physical address of that row, from the given RRN, results in a location that is either beyond the end of the dataspace or beyond the last valid physical row in the dataspace.

Regards, Chuck