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

Jerry,

I notice you have @ship and @datehd in the key but you're not testing those fields in your DoW statement. Don't think it's the cause of the problem but that's kind of odd.

Paul

Principal Programmer Analyst
IT Supply Chain/Replenishment

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

Paul,

Nothing weird about the key fields; i.e., they are all ascending. The only
thing is that the numeric fields, such as arco# are defined as packed in the
program, but the numeric portions of the key are all unpacked (signed)
decimal. But that's never been an issue in the past.

What I find extremely weird is that the program actually retrieves the
*first* record for the *next* customer.

Jerry C. Adams
IBM i Programmer/Analyst
The best cure for insomnia is to get a lot of sleep. - Senator S.I. Hayakawa
(California)
--
A&K Wholesale
Murfreesboro, TN
615-867-5070

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Morgan, Paul
Sent: Tuesday, July 05, 2011 2:01 PM
To: RPG programming on the IBM i / System i
Subject: RE: SETLL Not Pointing to Correct Record (V5R1)

Jerry,

Anything weird about the key on HISLIN? Could the sequence of the any of
the fields be reversed (DESCEND DDS keyword) on the key?

Paul Morgan

Principal Programmer Analyst
IT Supply Chain/Replenishment

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Jerry C. Adams
Sent: Tuesday, July 05, 2011 2:37 PM
To: RPG400-L
Subject: SETLL Not Pointing to Correct Record (V5R1)

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