Performance improvement – RPGLE

40 pts.
Tags:
AS/400
AS400 RPGLE
Hi, I have an RPGLE program which reads every record of a masterfile ( 4 million records) and updates some of the field values. There are different procedures to retrieve the values from various files and to update the masterfile. The procedures are written with read, chain logic to retrieve the value. The program is taking long time to run and I have to improve the performance. Can anyone kindly provide me suggestions? Thanks in advance Cv

Software/Hardware used:
as400

Answer Wiki

Thanks. We'll let you know when a new response is added.

I agree with Tom that we need more inforamation.

Is every record being updated?

Are you reading throught the file sequentially and is that file defined as an Update file?

I’m sure that using SQL and/or subprocedures will enhance performance.

Discuss This Question: 13  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • TomLiotta
    can anyone kindly provide me suggestions   There are no suggestions that aren't already in hundreds of sites on the internet, unless we see the programming and the database definitions, along with enough system specs to know what can be useful.   Most likely, the best suggestions are to alter the database structure to support SQL. Then convert the programming to use SQL and update sets of records at a time.   Not much more can be added without knowing more detail.   Tom
    125,585 pointsBadges:
    report
  • philpl1jb
    "retrieve the values from various files and to update the masterfile" for some cases  (small files with frequent use of value) moving these into arrays and using lookups instead of chains can improve performatnce considerably with little change to the overall program design.  
    50,415 pointsBadges:
    report
  • BigKat
    In cases where I want to do a mass update, I sometimes do go back to RPG's roots and use an unkeyed "Input Primary" driver file.  As long as there isn't complex reporting going on. 
    8,330 pointsBadges:
    report
  • ToddN2000
    If you are using any SETLL, READE, DOW or DOU check to seek if your key can be modified to cut down the number of I/O's being done. For example if  the current code does a SETLL then READE on CUST#  you may want to expand it to CUST#, DIVISION... You may need a few new logicals but it should help with performance.
    12,815 pointsBadges:
    report
  • TomLiotta
    ...moving these into arrays and using lookups instead of chains can improve performatnce...   Does it? I've never actually tested. If the files are indeed small, it's not clear why it would be any faster. An array lookup is essentially the same as an index search. And if the files are small and accessed regularly during the job, they may be brought into the memory pool anyway. (If not, then SETOBJACC can force them to be memory resident without changing the program logic.)   DB2 system-level code is reasonably efficient. It might be more efficient than coded program logic... if the database is appropriately designed. The design might be the biggest issue. Could be an interesting test.   Tom
    125,585 pointsBadges:
    report
  • philpl1jb
    Tom You're always right, but let me say that I am emotionally incredulous. and Incredulity robs us of many pleasures, and gives us nothing in return.   James Russell Lowell  
    50,415 pointsBadges:
    report
  • ZWANZIG
    Thanks everyone for your time. Please find the below code sample. They are reading each and every record and getting the field values through various procedures. Read Masterfile Dow Not%EOF select when dtatyp = 'ST' callp updtefld_ST when dtatyp = 'UR' callp updtefld_UR other callp updtefld_other endsl Read masterfile EndDo updtefld_st - procedure Eval name = get_name Eval Id = get_ID Eval code = get_code----- ----- ----  etc      
    40 pointsBadges:
    report
  • TomLiotta
    Please find the below code sample.   Good start. All we need now are database definitions, system/environment specs and the rest of the program, and then we can make progress.   Tom
    125,585 pointsBadges:
    report
  • philpl1jb
    What is get_name a field or a function?
    50,415 pointsBadges:
    report
  • ZWANZIG
    Hi Philip, get_name,get_code,get_id all are procedures. each of these procedures use CHAIN operation to retrieve the coresponding value from different files.  Thanks CV
    40 pointsBadges:
    report
  • harith
    use the CASE stament in Embedded SQL that will update the records at one shot
    170 pointsBadges:
    report
  • philpl1jb
    I love your code...but it's my understanding that each procedure call takes some extra cycles over subroutines or in-line code... I'm confident that Tom will straighten me out on that issue.
    50,415 pointsBadges:
    report
  • TomLiotta
    Previously I was only suggesting some actual benchmarks comparing CHAIN with array lookups. I'm almost interested enough to do them myself, but I'm not sure how many variables there are for such test cases. I'd like to believe that an integrated DB2 would be relatively efficient, but...? What OS version is running?   Anyway, I also like the general code structure that is suggested by the snippets we can see, though it's far from certain. We simply don't see enough.   For example, get_name, get_ID and get_code are all separate procs. But do they all access separate files? (Are the files global?) Do the secondary files all have the same keys? If any of the files are the same, does each proc still do its own CHAIN? The CHAINs themselves might not be much of a drag if there's no positioning, but the data movement might be excessive.   It's understandable to have procs to get values. It's not so certain that they're appropriate for this program. If keys match, perhaps a join VIEW or LF might retrieve many values at once into an externally-described DS. That could put code out of the program down into a lower, more efficient level.   Also, are file accesses retrieving entire record formats for PFs with many fields? Or are they LF formats only move the individual fields that are returned by the procs?   How many physical files are accessed? How are they related? How are they indexed? How are VIEWs/LFs defined over them? How many processes are competing for the same resources (files, memory pools, activity levels, whatever)?   In fact, what exactly is the whole point of this program? Reading through 4M records sequentially to update all/many/some/a few seems odd enough. What is business objective for this process?   We don't know near enough yet. From what I see, a few SQL statements might replace it all, e.g., one UPDATE for case 'ST', a second for 'UR' and possibly a third for "other", assuming that VIEWs/INDEXs exist. ut that's only from "what I see".  There isn't any visible program logic in what's been shown to indicate that procedural programming is needed. But we simply don't see nearly enough. We can't tell where any bottlenecks might be other than handling too many records, maybe.   Tom
    125,585 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following