× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.