Re: PF File Definition questions...

["Al Barsa, Jr." <barsa2@xxxxxxx>]

At 02:59 PM 10/14/1999 +0100, you 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)
> ?


Most folks define PFs with keys, as this makes them easier to use. 
SQL defines "tables" (PFs) without keys, and only defines
"views" (LFs) with keys.  SQL is the industry standard for
the definition of database files, which IMHO is inferior to DDS.

IBM is pushing us to use SQL because they are either stupid (do it like
the rest of the world, you dummies or go @#$% off) or cheap (same money,
[by not defining DDS interfaces to new stuff like BLOB/LOB support] make
the stock price go up, and when Lou quits, sell your stock and sell it
short).

Hopefully just before Lou quits, he will sell them AS/400 Division
(because it is clearly not strategic [in his opinion], because this will
make the stock go up more.  I hope that when Lou firesales the AS/4D
he calls us, because most likely everybody on this list would buy stock,
and after the AS/400 rules the world (from a technology perspective), we
would all have more money than Lou.


> 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 !!!!
I had a S/38 customer years ago who did a *ALLOBJ backup on
6 tapes (6250), which I found to be highly suspicious.  When I
migrated them to their AS/400, I told them to be sure to specify
ACCPTH(*YES), and they showed up with 30 tapes!  Their "order
detail" physical file had 125 LFs on it!

Al

+--------------------------------------------------+

| Please do not send private mail to this address. |

| Private mail should go to barsa@ibm.net.         |

+--------------------------------------------------+

Al Barsa, Jr. - Account for Midrange-L

Barsa Consulting, LLC.  

400 > 390

Phone:          914-251-1234

Fax:            914-251-9406

http://www.barsaconsulting.com

http://www.taatool.com