Bad performance in call command in RPGLE

75 pts.
Tags:
RPG
RPG Program
RPG/400
RPGLE
SETON
We are facing a bad performance issue when RPGLE pgm A is calling RPG pgm B. Pgm A is reading a file as primary that contains 1000000 records and for every record calls pgm B that is doing 1 chain to a file and if it's sucessfully updates another file and then RETURN (not with SETON LR) to pgm A for reading next record. When we run this process it takes 3 hours to complete. We do not want to put the code of pgm B in pgm A as we want pgm B to run like an api. Please could you advise how we can bypass this performance issue ?

Answer Wiki

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

Hi,

Why do you use RPG instead of RPGLE for program B? If you convert program B to RPGLE you could use this program (B) more efficiently.

I’m also not sure whether using primary files in RPGLE is still more efficient. In RPG this was true, but in RPGLE I believe that the benefits of primary processing are less than they used to be.

Are you using commitment control in any of these programs?

Regards,

Martin Gilbert.

All of Martin’s comments/ideas plus
you say “1 chain to a file and if it’s sucessful??ly” — are you using the data from this file or just record existance? could this chain be replaced by SETLL using the %EQUALS?
Phil

——
The dynamic call to program B for each of the million records to be processed is a lot of overhead. Expanding on Martin’s idea, if you convert program B into RPGLE, you could bind them together as one program object and eliminate the overhead of the dynamic call.

You would compile program A and B as modules and change your CALL statement in program A to a CALLP and add a prototype in order to call program B (bind by copy). Or to bind by reference, you could create a service program from the program B module and bind that service program to program A.

CWC

Discuss This Question: 1  Reply

 
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
  • Yorkshireman
    Not much to go on in your question. You can a) improve the efficiency of the existing structure - as other say, convert and recompile gm B into RPGLE for an immediate gain. THen you can alter to a bound call, for another gain. Then you could look at b) restructuring the code. The first thing to do (even in RPG/400) is to replace CHAIN with SETLL - huge, huge, performance gain. User OPEN FILE B and explicitly leave it open. you say you are already not setting LR on. Ensure that PGMB remains in storage. If File A is keyed, consider if sequential access would be faster c) restructuring the environment If PGM A is running a primary read on FILEA, then calling PGM B to chain to FILE B, then we can infer that File B has a relationship to FILE A. Can you provide an access path joined across both, perhaps with a select on FILE B data and read THAT as a single operation? Or run the join dynamically with SQL, or even good old Query to generate an output file of 'only' records where FILE B exists? - building an access path takes place down in the MI layer, and is much more efficient than RPG You say you want PGM B to run 'like an API' as though you foresee its re-use elsewhere. Read about service programs and modules, and write it in a form for re-use - as a bound procedure.
    5,580 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