RE: SETLL Not Pointing to Correct Record (V5R1)

Tommy,

Sorry to be so late replying; I filed the message just before leaving on
Tuesday and was out yesterday.

I'll try the READE, but I only added the ##seq field after the first series
of tests failed. Thought it wouldn't make any difference, but I was
desperate for anything by then.

Jerry C. Adams
IBM i Programmer/Analyst
Sex will outlive us all. - Samual Goldwyn
--
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