× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Huh?  I reade will progressively read thru record after record until it 
finds a non-matching record to the key.  Why would you want to skip the 
reade and then do an if comparision when reade does it all in one step?  A 
chain finds the very first record, a reade finds the next matching record. 
 So they aren't the same.

Ron Power
Programmer
Information Services
City Of St. John's, NL
P.O. Box 908
St. John's, NL
A1C 5M2
709-576-8132
rpower@xxxxxxxxxx
http://www.stjohns.ca/
___________________________________________________________________________
Success is going from failure to failure without a loss of enthusiasm. - 
Sir Winston Churchill




"Fleming, Greg \(ED\)" <GFLEMING@xxxxxxxxxxxxxxxxxxxx> 
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
2005/11/23 09:23 AM
Please respond to
RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>


To
"RPG programming on the AS400 / iSeries" <rpg400-l@xxxxxxxxxxxx>
cc

Subject
RE: Optimizing File I-O in RPG IV/ I-Series






Don't do a READE.

Do a READ and then leave when you get to a record you don't want.
Doing a READE is like Chaining over and over again. 

Greg

>-----Original Message-----
>From: rpg400-l-bounces@xxxxxxxxxxxx 
[mailto:rpg400-l-bounces@xxxxxxxxxxxx]
>On Behalf Of Weber, Richard
>Sent: Wednesday, November 23, 2005 7:49 AM
>To: 'RPG programming on the AS400 / iSeries'
>Subject: RE: Optimizing File I-O in RPG IV/ I-Series
>
>Maybe you're already doing this: Skip the update statement for records
>whose
>data hasn't actually been changed.
>
>Rick Weber  |  TOYS 'Я' US International
>
>-----Original Message-----
>From: Jim Wiant [mailto:Jim.Wiant@xxxxxxxxxxxxxxxx]
>Sent: Tuesday, November 22, 2005 7:18 PM
>To: rpg400-l@xxxxxxxxxxxx
>Subject: Optimizing File I-O in RPG IV/ I-Series
>
>We have a series of programs that update files for assorted maintenance.
>The time these programs are taking is becoming excessive.
>
>In most cases, the RPG code is very simple.
>
>Key             SETLL                                           file
>Key             READE                                           file
>                (Do until EOF)
>                UPDATE                          record
>Key             READE                                           file
>                END DO
>
>I don't see how the code can get might tighter. Is there any reasonable
>compiling options/ CL overrides, etc. that could improve such a routine
>when it
>needs to process a large number of records? We're not opposed to
>changing code, but if just a few H spec changes and/or compiling options
>could gain
>us a bit of performance, it would help us out.
>
>I've tried a few of the basics (OPTIMIZE(*FULL), NoDEBUGIO, etc.) but
>didn't see much of a change in my benchmarks.
>
>Thanks for any help
>
>Jim Wiant
>
>
>Once a job is fouled up, anything done to improve it makes it worse.
>Finagle
>
>
>This message has been sent from Foodstuffs (Auckland) Limited
>("Foodstuffs").
>
>The information contained in this message and or attachments
>is intended only for the person or entity to which it is
>addressed and may contain confidential and/or privileged
>material. Any review, retransmission, dissemination or other
>use of, or taking of any action in reliance upon, this
>information by persons or entities other than the intended
>recipient is prohibited. If you received this in error,
>please contact the sender and delete the material from any
>system and destroy any copies.
>
>The views and opinions expressed in this message may be those
>of the individual and not necessarily those of Foodstuffs,
>and are not given or endorsed by it.
>
>Please note that this communication does not designate an
>information system for the purposes of the Electronic
>Transactions Act 2002.
>--
>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.
>
>========================================================================
>This email message is for the sole use of the intended recipient (s) and
>may
>contain confidential and privileged information. Any unauthorized review,
>use, disclosure or distribution is prohibited. If you are not the 
intended
>recipient, please contact the sender by reply email and destroy all 
copies
>of the original message. To reply to our email administrator directly, 
send
>an email to EmailAdmin@xxxxxxxxxxxx
>Toys "R" Us, Inc.
>
>--
>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.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.