× 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.


  • Subject: Re: FW: update files
  • From: Jim Langston <jlangston@xxxxxxxxxxxxxxxx>
  • Date: Thu, 06 Jan 2000 07:46:14 -0800
  • Organization: Conex Global Logistics Services, Inc.

Basically, it just depends on how many records you have in the
database file you are updating.  If it is a 2000 record file, it doesn't
much matter what method you use, it's going to go by so quickly it
won't matter.  On the other hand, if your database file is 500,000
records + and you are only updating 20 records, you can see the
waste involved.  You have to read all 500,000 records to change
20 of them.

I don't believe it is anywhere near as CPU intensive as a GSORT
or COPY, and it does not take an unreasonable amount of time,
with the files I am updating ranging from 20,000 to 500,000
records.  With the 20,000 records it takes a few minutes, I have
never timed it though.  With the 500,000 it is something like 5 to
10 minutes I think.  This is very reasonable for something I am
updating on a one time basis and won't bring my CPU up too
high.

If I was going to add this to a production program, however,
I would definitely either try to change the program to be more
efficient, maybe by looking at the ramifications of building a
logical file for the fields I am wanting to change, but I would only
do that if the logical file would be useful to the system, or by
putting the process in batch mode whenever I could.

I have ran this type of program and done a WRKSYSACT and
my job does not take up an inordinate amount of CPU time, even
while running interactively.  Obviously, however, I am using a bit
of the DASD.

As far as UP .vs. roll-your-own, I *think* that UP is much more
efficient, just because that is the way RPG was designed.  The
only real way to find out, of course, is to write the same program
as UP and roll-your-own and run them.  See which is faster.

In conclusion, imo it would be acceptable to run this type of
update process in batch mode as long as you don't need the
results immediately and your normal CPU and DASD usage is
at a reasonable amount.  There really aren't too many ways to
get around it anyway, except by the logical method, I think.

Regards,

Jim Langston

boothm@earth.goddard.edu wrote:

> Is there any way of knowing how "not very efficient" this choice is?  I
> know that when I use UP and take off the K in the file spec these programs
> are stunningly fast.
>
> Does Barbara have any info to share on UP to a sequential file vs. a
> roll-your-own-cycle job?
>
> _______________________
> Booth Martin
> boothm@earth.goddard.edu
> http://www.spy.net/~booth
> _______________________
>
> Jim Langston <jlangston@conexfreight.com>
> Sent by: owner-rpg400-l@midrange.com
> 01/05/2000 01:09 PM
> Please respond to RPG400-L
>
>
>         To:     RPG400-L@midrange.com
>         cc:
>         Subject:        Re: FW: update files
>
> FMyFile   UP   E               DISK
>
> C             If           DType = 'JRNL' And DDStat = 'A'
> C             Eval       DDstat = 'X'
> C             Update  MyFile01
>
> Assuming: file name is MyFile and record layout is MyFile01
> That will do it for you.  This will read through every record in
> MyFile and update as per your specs.  This is not very efficient,
> however, as it does have to read through every record.  It does
> this because the file is opened as the Primary file, and uses the
> RPG cycle.

+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---


As an Amazon Associate we earn from qualifying purchases.

This thread ...

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.