×
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.
500 records does not seem like much, so my guess is there must be a lot of
program i-o just to create one subfile record, or some
other cause of the use of more than one minute of clock time - by
the way, how much cpu time does the system
show has been used in that amount of clock time? Also, from the
WRKACTJOB display what do statistics do
you see during the long wait?
Andy Devries <andyd@xxxxxxx>
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
01/18/2011 03:08 PM
Please respond to
RPG programming on the IBM i / System i <rpg400-l@xxxxxxxxxxxx>
To
RPG programming on the IBM i / System i <rpg400-l@xxxxxxxxxxxx>
cc
Subject
RE: Subfile initial load very slow
I hope this is what you are asking. When I looked at the job when it
completed (loading and displaying the subfile). I read 4 different data
base files to produce one subfile record. The actual subfile ends up
containing just over 500 records.
After the initial load, it is possible that the subfile could be reloaded
- the file is static enough that new records would not be added.
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Gary Thompson
Sent: Tuesday, January 18, 2011 1:43 PM
To: RPG programming on the IBM i / System i
Subject: RE: Subfile initial load very slow
More questions to focus on the reason the initial load seems so much
slower:
1) Do you know about how many records are read from the database
to load one subfile record?
2) After initial load, is the subfile reloaded, or are new records
added to existing subfile records?
By tracking program i-o, you might find that performance is not changing
as much as the amout of program i-o is changing
In my experience, subfile i-o is relatively fast compared to database i-o
Andy Devries <andyd@xxxxxxx>
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
01/18/2011 02:21 PM
Please respond to
RPG programming on the IBM i / System i <rpg400-l@xxxxxxxxxxxx>
To
RPG programming on the IBM i / System i <rpg400-l@xxxxxxxxxxxx>
cc
Subject
RE: Subfile initial load very slow
Thanks Paul - The program is a simple call from a CL - Displays the
subfile screen with input fields. Once <ENTER> is hit the subfile build
happens. It's the time between the build and redisplay that can be very
long. Not all 3000+ records are part of the subfile.
On Behalf Of paultherrien@xxxxxxxxxxxxxxxxxx
Sent: Tuesday, January 18, 2011 12:59 PM
To: 'RPG programming on the IBM i / System i'
Subject: RE: Subfile initial load very slow
Is there anything else occurring when the program initializes? It doesn't
sound like a subfile issue exactly.
Since it only occurs when the program is first loaded it indicates that
there is some initialization going on which may or may not have anything
to
do with the subfile.
Paul Therrien
Andeco Software, LLC
932 Saint Johns Dr
Maryville, TN 37801
225-229-2491
paultherrien@xxxxxxxxxxxxxxxxxx
www.andecosoftware.com
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Andy Devries
Sent: Tuesday, January 18, 2011 2:30 PM
To: rpg400-l@xxxxxxxxxxxx
Subject: Subfile initial load very slow
I've been scratching my head about this one for some time. This is an
RPG400
program. I have a subfile that is loaded from a file that only contains
3200 records. The initial load takes a long time (over a minute). In
subsequent calls to the same program, it responds much better (2-3
seconds).
I've gone into debug - doesn't seem to hang at any location. I've watched
it process (WRKACTJOB) and it seems to do the same process. I have looked
at locked records - doesn't seem to be a problem. Can anyone suggest
other
techniques for debugging this problem. As you can imagine, the users
don't
like the long delay.
Andy
As an Amazon Associate we earn from qualifying purchases.
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.