Re: PF File Definition questions...

Chuck,

Our shop standard is arrival PF with one unique key LF and that unique
LF is implicitly used for a shared ODP LF.

There are times when we blast through the sequential PF (taking
advantage of blocking) and do a CHAIN to the logical for changes.  This
is when we don't know, in advance, how many records may be affected by
what we are trying to do.  There are times where this technique will run
faster than the time it takes OPNQRYF to build a subset logical.

The shared ODP LF is used in all programs that CHAIN to a file or ALWAYS
assumes it must set the file cursor for READ.  We avoid getting cute
with PGMA doing a CHAIN/SETLL and PGMB doing a READ.

The nonshared LF is for primary/secondary processing purposes usually in
batch "type" jobs.  IMO, a prompt/OPNQRYF/print type job is a batch
"type" even if it is run interactively.

Beyond that, we create logicals based upon performance requirements.

Although, off the top of my head, I can't think of any file we have that
has a hundred LF's, a 3 year historical file with individual LF's by
YEAR/MONTH plus a few more can get you an easy 50.

BTW, an access path is an access path.  AFAIK, there is no gain by keyed
physicals.  The key is still an access path.

Chuck Lewis wrote:
> 
> Hi Folks !
> 
> Was wondering how folks define PF's when it comes to keyed or not.
> 
> Is there something I'm missing when it comes to NOT having the "most
> common" field(s) in a PF defined in the PF a key field(s) ?
> 
> Then handle the less obvious stuff in LF's ?
> 
> One less access path...
> 
> Why PF's with NO key fields ?
> 
> Also, I was told YEARS ago (on the S/38) that you should try to keep the
> number of LF's over a PF to a minimum, say 3, 4 tops and let your
> program handle the level breaks, etc. to help system performance. Even
> on the AS/400 there has GOT to be some truth to that just due to the
> fact that there aren't a BUNCH of access paths that have to be rebuilt.
> I've seen some vendor packages with a hundred LF's over one PF !!!!
> 
> Thanks !
> 
> Chuck
>
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---