Re: Interactive Response Time

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)