× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: PF File Definition questions...
  • From: "Al Barsa, Jr." <barsa2@xxxxxxx>
  • Date: Fri, 15 Oct 1999 12:15:08 -0700

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

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.