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



That could be what I thought I remembered, but I don't actually remember...

I've spent a couple of hours writing records to a test file and CHAINing with a partial key and I can't get it to fail--it always returns the lowest value of the second field.

I suppose it might be some strange situation where the index blocks end up being split in an odd way, but that is pretty esoteric.

Sam

On 3/27/2013 5:42 PM, Roger Harman wrote:
One would *assume* you would get the first record by key order. Perhaps
not, though.

The documentation I found is ambiguous (at least to me). It says it will
find the first matching record on the access path. What does that mean? I
don't know but I found this posting that seems to reinforce your opinion of
randomness (actually, arrival sequence within the first key segment).

http://www.mcpressonline.com/forum/showthread.php?12362-SETLL-READ-vs-CHAIN
Post #5

<quote>:
<snip>
I was told by someone a long time ago (he was supposedly an IBM guru) that a
chain will get the first record of a partial key in arrival sequence.

So, if FieldA was 10, Filed B was 20 in 20 records and FieldC was 1 through
20. If the records were originally written in FieldC order, the first record
should be correct beacuse the arrival sequence/RRN order is the same as the
key order. But if the records were written where FieldC values were
15,6,8,20,1... not in order by the key field, the first record retrieved by
the partial key would be where FieldC=15. If the full key is used in the
chain, it reads by the key order. CHAIN was never intended to be used as a
substitute for SETLL. At least that's what the guru said. I don't use CHAIN
anymore as a SETLL. I'm using free-format and it's a pain to deal with
%FOUND, %EOF.
</quote>



-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Sam_L
Sent: Wednesday, March 27, 2013 2:19 PM
To: rpg400-l@xxxxxxxxxxxx
Subject: CHAIN on a Partial Key
I have a logical file uniquely keyed on ITEM and WAREHOUSE.

I have found an (incorrect) program that does a CHAIN to this logical using
just ITEM. (The assumption may have been that it would get the lowest
WAREHOUSE which is where most stock is, but it is old code and I can't ask
anyone.)

I believe it sometimes gets a record that isn't the lowest WAREHOUSE and
ITEMS sometimes vanish from a report because there is no stock in this
warehouse.

Some eagle eyed person found items missing from a report from last year.
We restored the PF and the LF from a backup tape to another library, reran
the report, and the missing items correctly turned up.

I believe that there is no guarantee that if you do a CHAIN on ITEM that you
are guaranteed to get the record with the lowest value of WAREHOUSE and that
randomly we get another record.

Others are skeptical that I have found the cause, but it is a complicated
program stack and we haven't found any other reason.

Question 1: Am I on solid ground with my belief?

Question 2: Does any one know of any documentation on this subject?

Thanks, Sam



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