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

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?.

Back on the S/38 and in early OS/400, damage to files was far more common than it is today. Power requirements were higher, UPSs were less common, stability could be affected more easily than in later releases, etc.

Recovery of data in a PF could often be done by reading the PF in pure arrival sequence as long as the PF itself had no index/key. If a
LF key suffered damage, it wasn't much of a problem -- delete it and
recreate it; the damage to the LF index was physically separate from
the PF object that held the data.

But there were circumstances where damage to a PF /index/ would interfere with reading the physical records even when trying to read without reference to the index.

When the physical index was damaged, arrival access path processing was still possible, albeit not with utilities like CPYF and OPNQRYF. And the reason the CPYF or other utilities would fail, was because they extract information about the file before opening, failing on errors; not to justify that behavior, only to state what they did. However most any HLL compiler could be agnostic for index existence, when the defined access was non-keyed. So even if a compiler did extract the index information for the file, causing the compile to fail, a compile could simply be redirected by an override to an /equivalent/ file [that has no index, or least not damaged], and the arrival sequence access path used at runtime.

Because you couldn't create a LF that presented records in a reasonably pure arrival-sequence fashion, the PF became the _only_ possible way to access record by record. It's _possible_ that a non-keyed LF today might allow useful arrival-sequence access if damage occurs to a PF index. (I don't have a clue whether it actually
would; I'm just dredging up old memories, probably jumbled.)

I am not aware of any time when the K specification [NameType=K] was required in LF DDS; maybe Join, and less maybe Multi-Format.? Again, limited experience on S/38, but I remember creating many LF which were nothing more than SQL VIEW, in fact to test SQL VIEW for its r112 debut. Row level access against a non-keyed DDS LF actually defaults to arrival sequence access. So too a CQE query when the KEYFLD(*FILE) is specified and the queried file has "an arrival sequence access path, in which case the query record arrangement matches the arrival sequence of the first file, member, and record format specified for the FILE parameter."

Regardless, the rarity of damage to [indexes plus data spaces] today
seems to have made the early issue(s) with PF keys almost entirely
moot.

Anybody know more details from way back then? Do reasonable reasons exist today? (Disregarding tables that don't need keys in the first place, etc.)

The bigger problem with a damaged PF index was that a backup of the data by SAVOBJ could not be effected. That is because the only way the keyed PF can\will be saved, is when the index is part of the save. Save is intolerant of damage. The LF indexes can be omitted by ACCPTH(*NO), or as noted they can be deleted, if any are damaged & causing problems. So after the physical index was damaged, one could not simply make an immediate backup of the file.data, they had to first copy the data to another file to save the data. Of course the other file could have been a Tape File, but that has never been popular, and besides, the easiest method provided was CPYTOTAP, and as a system utility it may also have performed an extract including information about the index which would have caused it to fail.

If a constraint index were damaged, much like a logical file index, that can be deleted. But instead of DLTF, using the RMVPFCST and the appropriate reply value to the inquiry, to effect the index removal.

Regards, Chuck