Bad performance in call command in RPGLE
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 ?
Software/Hardware used:
Software/Hardware used:
ASKED:
February 15, 2009 12:57 PM
UPDATED:
February 19, 2009 8:59 AM
Answer Wiki:
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
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.