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
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
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
Anybody know more details from way back then? Do reasonable reasons
exist today? (Disregarding tables that don't need keys in the first
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.