|
Do you have programming standards that include performance considerations? Here are some examples from what I use. I try to label my categories in a contentious manner to indicate stuff that it is not a good idea to be doing if we can avoid it. My terminology is NOT what you will find in official documentation. Also my notes were made when I thought I understood a reality on an old OS/400 version by today standards, so some of this stuff might no longer be valid. The way some of this is phrased, I have not yet figured out the best way to implement these ideas, DATA SLICING Many programs look at ALL records in relevant files to locate those records that are needed for a particular application or function. But many user functions only need to access a narrow slice of the total data, relevant to a particular facility, customer, item, etc. How much faster do you think a program might function if it did not have to look at irrelevant records to determine that they are irrelevant? How much less drain on overall computer system do you think the program might have impacting all other users, if it was accessing only the relevant records in some files, instead of 1,000 times as many records as neccessary? One way to modify programs to achieve data slicing is to look at logicals structured according to selection criteria that parallels what criteria the program is using to say what is relevant, such as status codes, warehouse id, etc. RANDOM DISK DRIVE JUMP AROUND AS INEFFICIENTLY AS YOU CAN There is an RPG command "Data Base Get by Key" which performs efficiently when executed no more than a couple dozen times per user when interactive but performs inefficiently when in batch mode ... you need to understand READ vs. READE performance in interactive vs. batch & check program logic for if a lot of reads will be needed in an execution ... for some programs, we may want slightly different logic conditioned on if the program is running interactively or batch. PM/400 data will tell us which programs have this problem. READ RECORDS SEQUENTIALLY AND TAKE ALL DAY ABOUT IT Many RPG programs do SETLL then a READ loop within some index range. Performance can be dramatically improved by using a logical in sync with what the program needs to access & CL call for OVRDBF SEQ ONLY(*YES) provided we have good blocking via relevant NBRRCDS ... check midrange_L archives for SETOBJACC & OPNDBF STOP START STOP START GET NOTHING ELSE DONE check out called programs & make sure you do not call for end of job when there is a high probability the program will be called again ... when the outer caller ends the inner called also end. ie. RETRN means much better performance than LR since the opening & closing repeatedly of the same program starting & stopping can be a CPU drain. UPDATE PRODUCTIVELY When a file is being read sequentially & only SOME records get updated, it pays to define the file twice, one definition for the reading & another for the updating, because there is overhead associated with access to a file for update & if you are only updating a handful of accesses in which all have this overhead, that is hogging system resources unneccessarily. USERS FIRING SQUAD AT AS/400 PRODUCTIVITY When an army of workers arrive & sign onto the system at 8 am or whenever & all leave at 4.30 pm the system is hit with a performance hit for everyone else. What can you do for them other than warning them in advance about this scheduled performance hit? Apparently there is a way to assign extra storage to individual user profiles, so the damage is a bit less. WRITE ONE RECORD AND TAKE YOUR TIME ABOUT IT The same program can access the same file using different logical names for different logical functions - read / update / write / delete When a program is accessing a file using same name for several functions, this impairs productivity of system resource access. MacWheel99@aol.com (Alister Wm Macintyre) (Al Mac)
As an Amazon Associate we earn from qualifying purchases.
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.