RE: SETLL Not Pointing to Correct Record (V5R1) -- RPG400-L

Jerry,

You were showing us the code 'under the lamp' because it was easier to look for 'the keys' there (grin). Glad you found the problem.

Thanks,
Paul Morgan

Principal Programmer Analyst
IT Supply Chain/Replenishment
508-253-3934

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Jerry C. Adams
Sent: Thursday, July 07, 2011 10:06 AM
To: 'RPG programming on the IBM i / System i'
Subject: RE: SETLL Not Pointing to Correct Record (V5R1)

Well, I knew the answer was going to be silly (aka dumb). I had every
confidence that SETLL still worked plus I had another procedure that loaded
a different subfile from a different table that did work.

I stared at the code for so long that I saw what I was expecting. The
database fields that are (were) being tested at the top of the DOW loop were
from the *header* table, while I was trying to read the *lines* table. No
one looking at the code I attached would have known this, of course.

Jerry C. Adams
IBM i Programmer/Analyst
This portion of "Women on the Run" is brought to you by Phillip's Milk of
Magnesia. - Harry Von Zell, radio announcer (1950's)
--
A&K Wholesale
Murfreesboro, TN
615-867-5070

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Tommy.Holden@xxxxxxxxxxxxxxxxxxxxx
Sent: Tuesday, July 05, 2011 1:45 PM
To: RPG programming on the IBM i / System i
Subject: Re: SETLL Not Pointing to Correct Record (V5R1)

2 thoughts:

1) drop the ##seq field from the key list and use READE instead of READ
2) check %EQUAL after the SETLL

From: "Jerry C. Adams" <midrange@xxxxxxxx>
To: "RPG400-L" <rpg400-L@xxxxxxxxxxxx>
Date: 07/05/2011 01:38 PM
Subject: SETLL Not Pointing to Correct Record (V5R1)
Sent by: rpg400-l-bounces@xxxxxxxxxxxx

I am at my wit's end. Worse, the fix is going to be so bloody obvious,
but
I have been looking at this all day. This is probably going to be way too
much information, but I didn't want to leave anything out.

I have a program that builds a subfile of documents in a History Header
table based upon a customer number and a starting date. That part works
fine. The user may select any document to list the lines within it, which
are located in a History Lines table. This is where the fun starts.

You will notice in the code below that I'm using a KLIST to SETLL on the
file. That's because in V5R1 there is no %kds() function, much less am I
able to use something like SETLL(fielda:fieldb) SOME_FILE. I've used
KLIST
for SETLL in other parts of the program, and they work okay (that's how I
built the Header list subfile, after all) so I have no doubts that the
technique works - if done properly (which may not be the case here,
though).

But I am not getting the details for the invoice that I select, which is
generally in the middle of that customer's set of lines. Instead on the
initial READ, after SETLL, the record retrieved is the first line for the
next customer. I discovered that nugget when I put the program under
debug.
The values of the components of the KLIST, which I retrieved (F11) in
debug
are noted beside each KFLD.

As soon as the first READ is performed, I retrieved the value for BNCUST
(Customer#) and BNREF# (Invoice#). They were 00270 and 046801,
respectively. Beyond the code snippet I include a WRKQRY over the table
sorting it on the key fields. It shows the records I expected, the first
record of the next invoice for the same customer, and the record (for
customer 00270) that it actually read into the program. I, also, searched
on a DSPPFM of the table and found the original record that I was
expecting
just to double-check my sanity.

I am sure that the invoice header selected is the one passed to this
subprocedure not only because of the values retrieved in debug but because
I
also display header information at the top of the lines (detail) subfile,
and they match.

Any help would be appreciated.

Thanks.

Code:

P $HistDtl B

D PI

D @ref#hd Like(@ref#)

D @jrcdhd Like(@jrcd)

D @datehd Like(@date)

D @ship S Like(blspto)

D Inz(*Zeros)

D ##seq S Like(blseq#)

D Inz(*Zeros)

C HistLimit KLIST

C KFLD arco# 10

C KFLD ardv# 10

C KFLD ardp# 10

C KFLD aract 0110

C KFLD arsub 000

C KFLD @cust 00269

C KFLD @ship 00000

C KFLD @datehd 20110107

C KFLD @ref#hd 014850

C KFLD @jrcdhd AR

C KFLD ##seq 0000

/free

SF_Clear = *On;

WRITE ARQ042FCTL;

SF_Clear = *Off;

rrnf = *Zeros;

@nameaddr = %trim(@name) + '; ' + %trim(@city) + ', ' + @state;

SETLL HistLimit HISLIN;

READ HISLIN;

DOW not %eof(HISLIN)

AND bncust = @cust

AND bnref# = @ref#

AND bnjrcd = @jrcd;

rrnf = rrnf + 1;

@desc = bldesc;

@index = blindx;

@item# = blitm#;

@um = blum;

@price = blprce;

@upc = bliupc;

WRITE ARQ042F;

REAd hislin;

ENDDO;

rrnf_Max = rrnf;

IF rrnf > *Zeros;

SF_Display = *On;

SF_End = *On;

rrnf = 1;

ELSE;

SF_Display = *Off;

SF_End = *Off;

ENDIF;

DOW not eoj

AND not cancel;

WRITE ARQ042FFK;

SF_Folddrop = folddrop;

EXFMT ARQ042FCTL;

ENDDO;

RETURN;

/end-free

P E

WRKQRY:

Co# Div Dpt G/L G/L Cust# ShipTo Date Ref# Jr Seq#

Acct# Sub Cust# Cde

Acct

10 10 10 110 269 2011-01-07 14850 AR 21

10 10 10 110 269 2011-01-07 14850 AR 22

10 10 10 110 269 2011-01-07 14850 AR 23

10 10 10 110 269 2011-01-07 14850 AR 24

10 10 10 110 269 2011-01-07 14850 AR 25

10 10 10 110 269 2011-01-13 14961 AR 21

10 10 10 110 270 2006-04-07 46801 AR 21

DSPPFM View:

1010100110000002690000020110107014850AR

Jerry C. Adams

IBM i Programmer/Analyst

--

A&K Wholesale

Murfreesboro, TN

615-867-5070