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


  1.  Home
  2. RPG400-L
  3. January 2011

Re: Subfile initial load very slow

While I understand the technique you describe I don't know why anyone
would use it...in very limited cases the size may be static but anyway.

I guess I don't know how the buffers all work under the covers... SFLSIZ
SFLPAG.... in the RPGLE I'll write all the subfile records needed. I
always thought that was what was meant by a "load all" subfile. I loaded
them all in the subfile, with no reguard on how the system is pushing them
to the screen (that is for the system to decide). The only time I use a
subfile size that is more than +1 subfile page is when I need a fold. So
the other technique you describe, I've never used. And, as you suggest,
rightly so.


Thanks
Bryce Martin
Programmer/Analyst I
570-546-4777



Charles Wilt <charles.wilt@xxxxxxxxx>
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
01/19/2011 09:48 AM
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






Bryce,

Not surprising if you've used "extending subfiles (SFLSIZ > SFLPAG)"
as recommend. ie. You load more records when the user presses page
down. Example: SLFSIZ = 13, SLFPAG = 12. Program starts and loads 12
records. The next 12 are loaded when the user hits page down, page
down again and another 12 get loaded....at this point you've got 36
records in the subfile.

In this case, the OP has the subfile defined as "extending" but is
treating it as a "load all". This is not recommend and is often a
source of performance issues.

With a load all, you should have SLFSIZ = total # of records in the
subfile. Example, a subfile displaying the states of the USA should
have SLFSIZ = 50, regardless of how many you display per page.

HTH,
Charles


On Wed, Jan 19, 2011 at 9:05 AM, Bryce Martin <BMartin@xxxxxxxxxxxx>
wrote:
Sharon,
It may be the problem, but my suspicion is elsewhere. I have NEVER had
a
SFLSIZ that was more than 1 more than the SFLPAG. And I have NEVER seen
this type of issue. My guess is more of a datebase IO issue, files
being
opened, program not in memory, etc etc. You might be right, but from my
personal experience, I don't think that's it.


Thanks
Bryce Martin
Programmer/Analyst I
570-546-4777



"Wintermute, Sharon" <Sharon.Wintermute@xxxxxxx>
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
01/18/2011 05:12 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






Do you understand that by the system having to reallocate the subfile to
get it to 500 records from a definition (SFLSIZ) of 13, it is going to
take some time? That is 39 times it has to reallocate the subfile.
This is probably your problem.


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Andy Devries
Sent: Tuesday, January 18, 2011 4:08 PM
To: RPG programming on the IBM i / System i
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.

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx]
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

--
This is the RPG programming on the IBM i / System i (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 is the RPG programming on the IBM i / System i (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 is the RPG programming on the IBM i / System i (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 is the RPG programming on the IBM i / System i (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 is the RPG programming on the IBM i / System i (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 is the RPG programming on the IBM i / System i (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 message (including any attachments) is intended only for the
use of the individual or entity to which it is addressed and may contain
information that is non-public, proprietary, privileged, confidential, and
exempt from disclosure under applicable law. If you are not the intended
recipient, you are hereby notified that any use, dissemination,
distribution, or copying of this communication is strictly prohibited. If
you have received this communication in error, please notify us and
destroy this message immediately. ---
--
This is the RPG programming on the IBM i / System i (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 ...
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.