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



I'd also look at SQL..

Assuming you have multiple users running the program at once, the
problem with the work file idea is that you'd be repeating the same
work for multiple users. Whereas with SQL, any work the system does
for one user (ex. temp index @ v5r4+) could be shared by another user
with a similar query.

However, note that SQL access doesn't support "position to" very
well...it can be done, but it's much, much more complex... SQL is
better at filtering. It sounds like you might already be filtering
instead of the more common "position to" so this may not be a factor.

Also, you may find that instead of 80 LF's you need 37 or more
indexes....still that'd be an improvement.

Lastly, you may find that the current structure of the data doesn't
lend itself to better performance. Specifically, if the data has been
denormalized to support LF creation....the lareg amounts of repeated
data hurts SQL performance. You might need to restructure into a
"star schema" of the sort usually used by data warehouses to support
ad-hoc queries.

HTH,
Charles

On Fri, Jul 29, 2011 at 8:11 AM, Sharon Strippoli
<sharonstrippoli@xxxxxxxxxxxxxxxxx> wrote:
Good morning,

new job and given the assignment to revamp a screen pgm that the whole
company uses to make it more efficient, less CPU.

There are 12 different fields a user can fill in to search for the info they
want.  Plus there are fields they can check off for other criteria.  Total
about 25 different fields on the screen.

Currently, there are about 80 logicals that are used for all the different
combinations of fields to search on.  The first SUBR of the pgm does various
validations against all the possible fields, then depending on that result
does a SETLL for the appropriate logical.  Then a second SUBR checks the
fields again and depending on that does a READ, READE or READP against the
logical that was staged.

They want to select the data the first time through to a type of work file,
then as more information is filled in by the user, query or read against
that work file, drilling down further for each field that is populated by
the user.  They want to reduce CPU and the amount of logicals.
I was thinking of doing a query against the work file as it gets drilled
down.

Wondering how the super users that use this forum would take this on.  Any
input would be appreciated.


Thanks.


Sharon





Sharon Strippoli
Pilot Freight Services
IT Dept.
Phone (610) 891-8113
sharonstrippoli@xxxxxxxxxxxxxxxxx
http://www.pilotdelivers.com
--
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 ...

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.