On 28 Mar 2013 11:12, Crispin wrote:
I've always thought of the "Random" in "Random Retrieval from a File"
as a reference to how the programmer wants to access the data (as
opposed to sequential - READ/READE) rather than what the OS will
return.
The term /random/ in "Random Retrieval from a File" does indeed imply
the ability to position within the data to a specific row in the data
rather than processing every row from the current row to locate another
row. The computing term /random/ in RAM has the same implication. For
each, rather than /sequential/ reading [and writing] of data, the data
in any specific location can be accessed directly. One can /randomly/
choose a location to which to visit, ask the system to go there, and the
system does so directly without having to access everything between the
current location and the target location.
For processing by RRN, the term is generally the /direct access/
method, but that is also a /random access/ method. For processing by
key, the term used is often the /random access/ method but is also known
as and often referred to as the /keyed access/ method.
I have never liked the word /random/ in that context. I have in the
past tried to explain the /random/ as, given a Keyed Access Path being
traversed ordered from *START to *END, that each row retrieved from the
dataspace [for each specific key value] is found in an effectively
/random/ location [on disk] rather than contiguous. Contrast that with
the Arrival Access Path whereby each row that is retrieved from the
dataspace is in an effectively /contiguous/ location [on disk]. While
the reality is not exactly so, trying to rationalize the term /random/
seems more easily explained with that implication.?
In the OP's example, when the file has 2 keys I would expect CHAIN
KEY1 FILEX; to always return the same record, no randomness to it,
and that record should be the first record with the first key that
satisfies the second keys collating sequence (or FIFO/LIFO/FCFO etc.
as Chuck pointed out when there are duplicates) for a blank/zero
key.
The OP scenario is defined UNIQUE so duplicates do not apply. I am
not sure to what "blank\zero key" referred, but both collation and
duplicates are applicable irrespective of blank or zero key values.
I personally can’t see how that could ever be affected with a
subsequent release of the OS, it is the expected behavior for files
with compound keys. If it changed, I think there'd be a whole load of
broken software out there...
I concur. The results of the CHAIN should be predictable [except for
when a non-unique key has no specified Duplicate-Key-Ordering
specifications defined for the Access Path; i.e. no FIFO, LIFO, or FCFO
was specified].
On 28 Mar 2013 10:19, Charles Brewster wrote:
The definition of CHAIN is a Random Retrieval from a File.
If IBM tells me something is random, I take that to heart.
Because, how the database retrieval works today might not be how
it works under a different version of the operating system. There
are too many variables to try and decipher.
Except by defect corrections or for new function\capability [e.g.
sort sequence was new at some point], there should be few if any change
to how keyed retrieval works across all releases, past and future. That
is, the same Access Path and same access method via that AccPth should
be consistent across invocations and releases. One exception being for
unspecified Duplicate-Key-Ordering rules.
(does your file reuse deleted records?
Access Paths do not track deleted records. A CHAIN by key would be
unaffected by the answer to that question.
If all logical files are deleted and rebuilt, the
sequence they are rebuilt in also can have an effect)
In some very specific situations that can be an accurate allusion,
but in general and specifically for a UNIQUE keyed LF, there is very
little impact. The most likely issue is with Access Path *sharing* but
I am not aware of any way that would impact the scenario as described in
the OP.
As others have suggested, to eliminated all doubt, sounds like you
should be using SETLL and READE.
I was under the impression that the overwhelming majority were clear
both that the CHAIN would always get the /first/ row matching the key as
determined by the Access Path, and that the one anomalous report was
inconsistent with reality.
I am not sure how much trust one should place in a claim both that
"they say" and that "they" is some unnamed guru in IBM. Lacking a
specific APAR and PTF number noted in the old discussion thread from
2005, I find that the more likely situation was that the person writing
the message [writing effectively anonymously nonetheless; i.e. "Tom"],
really has little first-hand knowledge of what they wrote. FWiW that
message thread "Thread: SETLL+READ vs CHAIN" also seems to be missing
the original post; i.e. the message#1 seems quite
obviously\conspicuously to be a response to a prior message, rather than
an Opening Post:
http://www.mcpressonline.com/forum/showthread.php?12362-SETLL-READ-vs-CHAIN
I think the following link is worth reading, at least for the topic
"Random File Access", with regard to this current message thread:
https://scs.senecac.on.ca/~timothy.mckenna/RPG544/rpg_cls5.html
"...
* Random File Access key lookup: Record Address Type of "K" on F spec
o otherwise, retrieval is by relative record number
* purpose is usually to lookup and read a specific record during
batch or interactive processes
* Calculation Operation:
* CHAIN
o random retrieval of a record
o Factor 1 contains key value (or RRN)
o Factor 2 contains the file or record format name
o %FOUND means Factor 1 equaled a key in the file and the
record was read into program's data fields; to *OFF.
o NOT %FOUND means Factor 1 does not equal a key in the file;
program's data fields are not changed. %EOF(filename) is not reset.
o always gets the first record in a set of duplicate keys
o always gets the first record if Factor 1 is a partial key value
o Chain is equivalent to SETLL with %EQUAL followed by a READ
o a successful CHAIN positions the record pointer for next
Read operation
o N.B. %EOF and %EQUAL are not reset by the CHAIN operation.
o free form syntax offers more flexibility than the old fixed
format.
..."
Documentation is the IBM RPG ILE Programmer Reference.
http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/index.jsp?topic=%2Frzasd%2Fsc092508914.htm
Chain has been defined as random retrieval for as long as I can
remember.
Rightly or wrongly, confusingly or otherwise, the term /random/ means
to imply the ability to arrive at any specified row via a key value
rather than having to arrive by consecutively reading all contiguous
record data to arrive at a specific record from another.
midrange.com
