RE: Issue with chain and SETLL

["Joel Fritz" <JFritz@xxxxxxxxxxxxxxxx>]

If you have a customer master file, setll to that to verify the customer
number.  To validate a key value you never have to chain.

If you're dealing with a date range that doesn't necessarily end with
the most recent transaction you don't have any choice but compare the
file date with the end date.  The good part is that comparisons are
about the cheapest thing you can do.  You can put the comparison in your
loop control statement.

Regardless of the date range question, a logical by customer number,
date, and stock number is the easiest thing to work with assuming that
you're going to need that ordering to process the data.  If the customer
number is good, setll by customer number and min date.  Chain is bad
because there's no guarantee that the minimum date will be there for a
given customer. Go from there.  You can reade by customer number.
You'll kick out of the loop when you get to the last entry for that
customer number or the end of the date range for that customer number.

One thing to consider when writing screen programs is that optimizing
your code for speed usually isn't the most important thing. Since you're
mostly dealing with small record sets you don't have to squeeze every
drop of performance out.  Clear and easy to maintain should come first.
As long as the users don't have time to wonder why they're there it's
fast enough.

> -----Original Message-----
> From: rpg400-l-bounces@xxxxxxxxxxxx
> [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Douglas W. Palme
> Sent: Thursday, June 02, 2005 1:43 PM
> To: RPG Group
> Subject: Issue with chain and SETLL
>
> I am in need of some help......
>
> I have a LF that contains the following:
>
> 0001.00                 R SALES                     PFILE(IMPILN00)
> 0002.00      A            ILNSOLDTO                                
> 0003.00      A            ILNINVDATE                               
> 0004.00      A            ILNSTK                                   
> 0005.00      A            ILNQTYSHP                                
> 0006.00      A            ILNEPRICE                                
> 0007.00      A            ILNEUAVCST                               
> 0008.00      A          K ILNINVDATE                               
> 0009.00      A          K ILNSOLDTO                                
> 0010.00      A          K ILNSTK                                   
>
> What I am trying to accomplish here is display a subfile with
> stock totals for the various sales staff individuals for
> their respective customers.
>
> At first I had the primary K set to ILNSOLDTO so I could
> chain the file and verify the entered (coming from a DSPF)
> customer number is / was valid. 
> Then I need to do a SETLL for the specific data range they want....
>
> I really need to keep the records grouped by the customer
> number, then in date order and then by stock number, that way
> I can do a READE until the customer number changes and thus
> EOF display the data and I'm out.
>
> I know I can eval each record for the date but it seems that
> will only take a ton more time....correct? Incorrect?
>
> Suggestions or ideas would be appreciated.
>
> --
> This is the RPG programming on the AS400 / 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.
>
>

*****************************
NOTICE:
All e-mail sent to or from this e-mail address will be received or otherwise 
recorded by
The Sharper Image corporate e-mail system and is subject to archival, 
monitoring,
and review by and/or disclosure to Sharper Image security and other management.
This message is intended only for the use of the addressee and may contain 
information
that is privileged and confidential.

The contents of this message may contain personal views which are not the views 
of The Sharper Image.
If you are not the intended recipient, dissemination of this communication is 
prohibited.
*****************************