Re: CHAIN on a Partial Key

Sam, I would check to see if there is an ovrdbf to another file. If your
program says file ABC, doesn't mean that it's using ABC. It could be
overridden to DEF and maybe DEF is keyed by ITEM only. Level checks can be
avoided if the same override is issued at compile time. Just a thought.
You can verify the file that's being used by doing a DSPPGMREF. If
ovrdbf was used to compile you will see the file being overridden too
rather than the file in the FSPECS. If this is the case, lets say DEF was
by ITEM only, then it would get the first warehouse it finds by RRN.

Fstorer IF E K DISK
/Free
*InLR = *On;
Return;
/End-Free

ovrdbf storer STORERLE
compile the program above

dsppgmref testovr
3/28/13 Display Program References

DSPPGMREF Command Input

Program . . . . . . . . . . . . . . . . . . : TESTOVR

Library . . . . . . . . . . . . . . . . . : *LIBL

Output . . . . . . . . . . . . . . . . . . : *

Object types . . . . . . . . . . . . . . . : *PGM

Program . . . . . . . . . . . . . . . . . . . : TESTOVR

Library . . . . . . . . . . . . . . . . . . : MSCHUTTE

Text 'description'. . . . . . . . . . . . . :

Number of objects referenced . . . . . . . : 4

Object . . . . . . . . . . . . . . . . . . : STORERLE
<------ file being overridden too, rather than file defined in FSPECS.

Library . . . . . . . . . . . . . . . . . : WDLSDTEST

Object type . . . . . . . . . . . . . . . : *FILE

File name in program . . . . . . . . . . : STORER

File usage . . . . . . . . . . . . . . . : Input

Number of record formats . . . . . . . . : 1

Record Format Format Level Identifier Field Count

RSTORER 40811B1E9D140 153

Object . . . . . . . . . . . . . . . . . . : QRNXIE





Another option that comes to mind is maybe the file is being built into
qtemp and the program is reading from QTEMP instead and maybe that file is
missing the records you are expecting. I assume you've checked all this
though. :-)


On Wed, Mar 27, 2013 at 9:52 PM, Sam_L <lennon_s_j@xxxxxxxxxxx> wrote:

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.

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