Re: File open order (was: Order)

Hello Dare,

You wrote:
>Way back in '95, I learnt that it is efficient and good for performance
>to have the most processed files in ascending order.  That is, if you're
>reading a master file and branching off using CHAIN or READ to fetch
>other information you should have your master file first in the F-SPEC.
>Is this your understanding too.  If so, how do first open file relate to
>this concept of better performance programming.  Better performance
>programming meaning less burden on the system.

1) As others have noted, if you do not specify USROPN (or UC) on the
F-spec RPG will open files in the reverse order of the F-specs.

2) The order in which files are opened is completely unimportant if all
the files are used equally.  Your example shows a master file and one or
more secondary files (e.g. Order Header, Order Detail).  In this case the
order of open doesn't matter at all.  Your instructor was probably just
giving you a "rule of thumb" -- do it this way, it's good for performance
-- so even if you didn't understand WHY you would still get some benefit.

3) The only order that is important is frequency of use.  That is the most
used files should be together and the least used files should be together.
It doesn't matter if the frequency of use is in ascending or descending
order as long as the most used are at one end and the least used are at
the other end.  The worst thing you can do is put least used files in the
middle.  (In fact, files that are infrequently used should be USROPN and
only opened when actually needed.)

Why is it so?  Because the Open Data Paths (ODP) to the files are stored
in the Process Access Group (PAG).  The PAG is paged out to disk when your
job is idle and demand for main storage is high.  When your job becomes
active the system must bring the PAG back into main storage.  However, it
is intelligent about this and attempts to bring in only what it needs.  It
brings the PAG in 32KB chunks (as I recall -- it may have changed in later
releases) and it can trim the PAG by leaving unused portions out on disk.
However it can only trim the PAG from the ends.  Thus if least used files
are at one end of the ODP section of the PAG they can be left on disk
until they are really needed.  If the ODPs are all mixed up in any order
then they will (probably) all have to be brought in to main storage even
though many of them are not needed.

The performance aspect of ordering files is simply to reduce the amount of
work the system must do to get an idle job up and running again.

Having said all that.  The process of paging the PAG changed (I think at
440) and the PAG no longer has such a major effect on performance.  So it
probably doesn't matter any more.  Still, I tend to order my files as
described for the same reasons I order my subroutines and procedures from
most used to least used -- unless the procedures are in a service program
where the only thing of benefit is locality of reference and even that is
marginal.

Regards,
Simon Coulter.

--------------------------------------------------------------------
   FlyByNight Software         AS/400 Technical Specialists
   http://www.flybynight.com.au/

   Phone: +61 3 9419 0175   Mobile: +61 0411 091 400        /"\
   Fax:   +61 3 9419 0175   mailto: shc@flybynight.com.au   \ /
                                                             X
                 ASCII Ribbon campaign against HTML E-Mail  / \
--------------------------------------------------------------------