× 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.



Charlie,

I think you are missing my point. The strange things that are happening have nothing to do with the CHAIN. CHAIN should always behave as was expected. The only strange thing that could potentially happen is that someone misunderstand what should happen...

Crispin.

-----Original Message----- From: Charles Brewster
Sent: Thursday, March 28, 2013 3:51 PM
To: 'RPG programming on the IBM i (AS/400 and iSeries)'
Subject: RE: CHAIN on a Partial Key

Crispin,

I am not sure if it is just self-imposed or if I was told by someone when I was a young programmer, but I never, never, never chain with a partial key on a logical file. Strange things can happen and as we see from this thread, it is confusing to the programmers that follow behind you.

Maybe it comes down to programming "style."

In my book CHAIN is reserved for when I need to update a record in a file, the CHAIN should use a complete key that satisfies all fields in a unique logical file.

I use SETLL and READ/READE for everything else. (Sometimes the SETLL is enough and you never even need to do the read, performance bonus!)

Charlie


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Crispin
Sent: Thursday, March 28, 2013 2:12 PM
To: RPG programming on the IBM i (AS/400 and iSeries)
Subject: Re: CHAIN on a Partial Key

Charlie,

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.

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.

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 our there...

Crispin.

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. (does your file reuse deleted
records? If all logical files are deleted and rebuilt, the sequence
they are rebuilt in also can have an effect)

As others have suggested, to eliminated all doubt, sounds like you
should be using SETLL and READE.

Documentation is the IBM RPG ILE Programmer Reference.
http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/index.jsp?topic=%2Frza
sd%2F
sc092508914.htm

Chain has been defined as random retrieval for as long as I can remember.

Charlie

--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L) mailing list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at http://archive.midrange.com/rpg400-l.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
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.