SETLL and READE or CHAIN? Performance Issues

pts.
Tags:
Application development
AS/400
Billing and customer care
Billing Support Systems
DataCenter
Development
Functional
Performance/Load
Printing
RPG
RPG ILE
RPGLE
HI, I have a batch RPG programs used to do some updataions and reporting, currently the job takes around 1 sec to process a record. We want to further reduce this time. Changing the run Priorty may make the job run a bit faster, are there any other parameters that can be used? also am looking at more approaches like best coding practices for an RPG Programing as per performance say. Certain code sections have a SETLL and a consecutive READE statement, (using the same key)will using a single CHAIN operation have a performance benefit.

Answer Wiki

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

1 sec, elapsed or cpu ? if elapsed, measure can be wrong due to processor load > 95%.
Assume you can run in confortable situation to avoid mis-measures : check with WRKSYSSTS
- processor < 80 %
- not too much database page faults. no value to suggest, depends too much of context
- 0 act-inel
what is now the record run delay ? changed ?
1 sec is very too long. How many UNIQUE index implied in update ? all necessary ? if you update more than 70% of records think to rebuild index after running the prog.

in some case, OVRDBF NBRRCDS(…) can improve (this improvement may conflicts with unique index)

Are you sure you read each record only one time ? it’s a crazy way, but it’ a way of analyze

About CHAIN, SETLL+READ=CHAIN. if there is a difference, it is not remarkable.

Discuss This Question: 9  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
  • MariusM
    Hi, The CHAIN command does a SETLL and a READE in order to find a match. CHAIN is best used to locate a unique record (like a customer record) SETLL with READE is best used when there can be more than one record found. For example, you can find multiple customer orders in your system for one unique customer. I am not positive, but I would think that there could be a minor performance issue only if you are using the CHAIN command to locate all the orders for a particular customer instead of using the SETLL/READE commands. Increasing the priority of the job only makes it get processed sooner. After the job has been submitted, try increasing the "TIMESLICE" parameter. TIMESLICE (in milliseconds) is the amount of time the computer will work on your job. If it does not complete your job within the default TIMESLICE value, it will work on another job and then come back to yours. If there are lots of submitted jobs in the system at the same time, the computer will alternate between jobs for the amount of time specified in the TIMESLICE parameter until all jobs are complete. So ... if you double the TIMESLICE parameter value Try this: 1) WRKSBMJOB and press ENTER to see the list of currently running jobs you have in the system 2) Find the job you want, enter 2 as your option (CHGJOB) and press F4 to get prompted for the parameters. 3) Go to the 3rd screen and look at the top of the page for the word TIMESLICE. 4) Double the value and your job should only take half the time required to finish the job now. Hope this helps ... it's all I can think of at the moment. Hve a nice day. Regards ...
    0 pointsBadges:
    report
  • Beaufort
    Hello All - If the programmer is using SETLL and READE to get a single record you could change the program to CHAIN and get quicker results. The SETLL and READE is good only for situations where you need to read a group of records with the same properties (all records that have the same territory ID for example). The CHAIN will work better. Also, make sure your file is reorgaized so that all deleted records are removed. RGZPFM can be used. Finally, the creation of the file uses a parameter called 'Records to Force a write'. Check this parameter to make sure you are not forcing disk writes each time you write the record. And - reduce the logical files (DSPDBR) on the physical file, update the physical - not the logical. And - look at the access path maintenance parameters for the physical and logical files. With all of that you might have some luck - memory on the machine is important to consider as well - you might speed disk writes with better memory allocation / faster disk although now we are getting into some larger expense. Good Luck
    0 pointsBadges:
    report
  • Ayahel1
    You may also uthe SETOBJACC command. It allows you to "load" and object (*FILE or *PGM) to a subsystem memory pool. If a *FILE, allocate large amount of memory for the subsystem so larger portion of the file is loaded each time.
    0 pointsBadges:
    report
  • Byimw02
    From the information you provided, there may be performance issues outside of the RPG program logic. One second/record is not plausible for any HLL program. Changing the run priority and timeslice is the last adjustment needed. I would check if the logical maintenance parameters of the file being updated. Is the logical you are using set to *IMMED? If not, this can affect performance. Also are any other apps using the same file? There may be file or record lock issues. I would check for any DB issues before tinkering with the RPG program which may not yield any performance increases.
    0 pointsBadges:
    report
  • Ddune3566
    All of the other suggestions are good ones. Not enough disk space can slow things down. I don't know enough about your application to give a good answer. I would try putting the program in debug and see how many lines of code are processed in between your reade commands. If the file your are refering to is a master file and it is looking through a lot of detail and support files and reads these files and loops through code to process them this all can slow down the reads on the master file
    0 pointsBadges:
    report
  • BurtNoir
    The previous response reminded me of a situation I once discovered in a program that was taking far too long to process a record. In my case the program was using a setll / reade type loop to look for a particular record it needed. However, once it found the record it carried on processing the loop until the end of the file! Make sure that your program recognises when it has the data it needs and finishes the loop or at least issues another setll with the next key to be processed. hope that helps.
    0 pointsBadges:
    report
  • TomLiotta
    There is no reason to avoid CHAIN plus READE. It can in fact work better than SETLL plus READE. There is a programming 'style' element that prevents some developers from using CHAIN to prime a READE loop, but it is purely a matter of style. There is no logic to it. Tom
    125,585 pointsBadges:
    report
  • Vatchy
    It probably could be just a matter of style but it can also be clarity. If I see a SETLL and then a READE then I will be looking for the loop where I would expect to find processing on the record and then another READE.
    1,410 pointsBadges:
    report
  • Splat
    The difference between SETLL and CHAIN to position a file cursor is that SETLL doesn't load the buffer.
    7,395 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