Re: PF with lotsa LFs

[jpcarr@xxxxxxxxxxxx]

I've seen some crazy things in shops concerning LF's

LF1   key -  FLDA , FLDB, FLDC
LF2  key  -  FLDA,  FLDB

or
two,  three completely duplicated LFs because different teams never looked
thru the 50+  existing ones to see if one existed,  and just created a new
one.
or

LF1    key   FLDA    Select only   field CODE = 'C'
LF2   key   FLDA    Select only   fleld  CODE = 'O'
LF3  key   FLDA    select  only  field  CODE = 'D'

instead of

LFx  key   CODE, FLDA    (in RPG reading Equal on keylist)

or or or

Are many of your's  using select/omit  criteria?      Relook at your DB
design criteria.

You said you didn't use SQL because "SQL is not an option because it's not
available on all 400s."
If you have a compiled embedded SQL program,   using dynamic selects,   it
doesn't Matter if SQL exists on the other 400's if you are only concerned
if your programs would run.   Compiled SQL embedded programs will work
whether or not the "400"  has the SQL licpgm or not.

Are you selling your source for different machines?

Again ,    USE SQL  and I bet you could cut down on about 20 LF's ( IMO )
John Carr

Anyone ever have a file with 100+ logicals?

The design choice I'm facing is either fewer LFs but more complicated
inquiry programs & potential performance penalties vs. having many logicals
with simpler and quicker programs (less file reads).

Any wisdom on this?  Pitfalls?  Considerations?


Thanks...

Tom