Re: Why non-keyed PFs back then? Why today? ( was Re: Which of the SYSIBM tables/views show the row count for )

CRPence wrote:

Tom Liotta wrote:

Mike Cunningham wrote:

This may be a left over from the old days but we never put a key on
any table (Physical file) directly

IIRC (and _only_ IIRC), way back when, there were a couple elements that combined to bring a small amount of risk to having keys on PFs.

1. Non-keyed LFs were not allowed. (Possibly irrelevant.)
2. Damage to a PF index could make it impossible to read
the PF even in arrival sequence.

In my experience both 1> and 2> are false for OS/400. My very limited s/38 experience was with the last release, ¿r8?.

Perfectly possible and I won't disagree. I _thought_ that I first saw non-keyed LFs only after the first release or so of OS/400, but that's too long ago to be certain. I'll easily accept your assertion.

And it could also be true /in fact/ that reading in a pure arrival sequence would always work when an index on the PF was damaged. I had no way test to verify the validity. (I hope you had better tools available than we did!) However...

There definitely was a _belief_ that it had risks. Perhaps the belief was apocryphal. Regardless, the existence of such a belief was enough to keep the practice of non-keyed PFs alive in areas of the market. I ran into it at multiple sites and never saw an authoritative counter that I could use.

Beliefs can take on lives of their own. Lack of web sites such as developerworks and blogs by Kent Milligan made combating beliefs tough, much less learning for my own good.

So, the question remains -- WAS there ever a reason /in fact/ for non-keyed PFs?

(Again IIRC,) the SAVOBJ issue tended to appear during an attempted RSTOBJ. I.e., a save could complete without a clear warning of a problem; and when a problem was later noticed, the backup copy was already "damaged". Perhaps something like that would be an origin of the practice that eventually grew larger than the reality?

Tom Liotta