This chapter contains these topics:
Following are some performance issues you should consider when executing JD Edwards World software, changing current JD Edwards World programs, or writing new programs:
Purge your files on a regular basis to avoid excess, unnecessary records existing in files. The REUSEDLT *YES parameter on a Physical file can be used on files where records are deleted to minimize file expansion and contraction. G9645/14 will present a list of P98999 versions which can be used to RGZPFM the named files. The RGZPFM command, in general, removes deleted records and rewrites the remaining records in a file.
Minimize the number of open files in a program. If a file may not be used, define it as a User Controlled Open file.
Use User Spaces and User Indexes wherever possible.
Use File Servers and Functional Servers wherever possible.
Minimize the number of subroutine calls within your program.
Weigh the advantages of inter-program calls. Although this method is very modular in design, you should consider the effect on performance.
Substitute the comparison of a literal with the comparison of a variable.
For example: Use *ON and *OFF to set an indicator on and off rather that a 1 and 0.
Consider flexibility versus performance when using User Defined Codes, Vocabulary Overrides, and loading Data Dictionary values extensively.
One definition of "Performance Problem" is that some Dream Writers take a long time. The usual symptom is that the user does a Work with Submitted Jobs and sees the job spending a long time "indexing". Programs which have a very large based-on file are the prime suspects. P09800 is not a suspect!
The problem in these cases often involves the IBM Query File Optimizer. Simply stated, the optimizer tries to find an existing access path (logical file) that it can use to select records. If it can't find one or finds one that will return more than 20% of the file, it builds a whole new access path which takes a long time for large files.
The first assumption is that the applicable IBM PTFs have been applied.
On the DW Additional Parameters screen, there is a File Output Type field. An F1 on this field shows that values 2 and 4 use a logical file. If an existing logical should be used, enter a 2 in the File Output Type and the file name in the Override Logical File field. This setup often makes the DW run faster since the IBM Query File Optimizer is bypassed by using an LF rather than the OPNQRYF.
To have DW create the Logical File for you, enter a 4 in the File Output Type and blanks in the Override Logical file field. This option will use the DW Data Selection and Sequencing parameters to create a Logical File over the based-on physical, and will name it by replacing the P in the program name with an F and adding a 00n suffix.
IMPORTANT: You must then run the DW so the LF will be created. Then, before going back into the DW with a 2 to change, (which will cause the LF to be deleted) you must find the file using a DSPDBR on the based-on file. Do RNMOBJ so DW will not find this new file. Then, go back to the Versions list and enter a 2 to change the DW version. DW will automatically have changed the File Output Type to a 2 and have entered the name of the logical file it created. Enter the file name from the above RNMOBJ command.
When the File Output Type is a 2, the options for Data Selection Values and Data Sequencing Values will not show up on the change window. This is because the values in the LF will be used. If the values need to be changed, go to Step 3C.
On the DW version list, if you use option 7, you will see either the OPNQRYF statement or the DDS for the logical file.
The based-on file can be changed to a logical file attached to the Physical file, but then the File Output Type must be set to 1. This reintroduces the OPNQRYF command into the process using the Query File Optimizer. The Data Selection and Sequencing options are now available.