Re: Keyed source PFs? Why?

On 24-Sep-2015 16:15 -0600, Vernon Hamberg wrote:

On 9/24/2015 3:08 PM, CRPence wrote:

On 24-Sep-2015 13:36 -0600, Vernon Hamberg wrote:

Just ran into some keyed source PFs on our system - not all,
just some (probably) older ones.

So I've never even considered the possibility - is or was there
a reason for this?

Anyone more geezerish than I who remembers? Or knows?

:)

Because that is supported :-) Supported, both in a DDS-described
PF-SRC or a LF-SRC. Or more conveniently [without having to code
the DDS source], a parameter is available on the Create Source
Physical File (CRTSRCPF), the Access Path Type (ACCPTH). The
default for that parameter is *ARRIVAL but the parameter
specification of *KEYED is supported; the effect is to assign the
Source Sequence (SRCSEQ) field as the one key of a non-unique keyed
access path.

I have used that feature, almost exclusively, to allow for adding
rows sequentially to the end but to appear positionally [by key]
wherever they are necessary and for modifying rows to reposition
the data [thus also Allow Delete (ALWDLT) and Allow Update (ALWUPD)
also set to *YES]. Thus for a DDS-PF source, I can insert a row to
add a new field between others by specifying an appropriate
sequence number, or I can change the order of the rows and thus the
order of the fields within the RcdFmt simply by modifying the
sequence numbers, rather than by physically modifying the rows or
deleting and then re-inserting rows of the source.

<<SNIP>> I guess I'm still interested in the use case that suggested
it be done - I'm not THAT old on the 38 or 400 or successors that I'd
know about the earlier systems.

Again, just curious.

I do not recall if at all, or if only by System/38 CPF8, had there even been a Create Source Physical File (CRTSRCPF) command. But I am fairly sure that at least some releases prior, the means to create such a file available only via the one command: Create Physical File (CRTPF) using the FILETYPE(*SRC) specification.

I surmise that the keyed support came way back then, with CRTPF, for whatever was their intent [seems logical, as the sequence numbers really only make sense when collated ascending]. And that the new command [for compatibility reasons] carried the same support; presumably before CRTSRCPF came, the CRTPF had the same limitation of the first field being the "Only one key field allowed in source file" per CPD7952, just like other restrictions for the /source/ designation, such as the first field was also restricted to 6S02 and the second restricted to 6S00.

My own use was for dynamically modifying DDS-PF and DDS-LF sources, rather than storing all possible iterations in separate source members; the variations of the sources was for LFs mostly [but sometimes PFs] that were produced at run-time with some row updates and/or additions. Distinct but mildly different record formats or select\omit can be generated dynamically rather than being stored; surely anyone storing sources recognizes sometimes the minor differences would easily be effected by a simple insert into the proper relative position.?

Also, but on a rare occasion, when Start Source Entry Utility (STRSEU) was not available, the keyed nature of the source file was useful for when Update Data (UPDDTA) [under the Data File Utility (DFU) umbrella] or command-line /insert/ utilities were the only available means to update a source member.

I recall later uses of the same technique for dynamically updating QM Query source members, perhaps even a QM Form source member; I could insert a WHERE clause, or a WHERE or a JOIN predicate, optionally with a variable.

Combined with SRC-LF members, [re]generated Dynamic Select (DYNSLT) logic to pick rows from much larger sources combined into one source physical member allows reduced storage for the distinct full-sources. For that, mostly logically paring records with the Compare (COMP) keyword in the logical, rather than physically changing\inserting records; the dynamic update to the physical source was limited to the DDS for the LF, setting the appropriate COMP.

Anyhow, the compilers [all should] default their open, much like Open Database File (OPNDBF), using the Access Path (ACCPTH) of the file; i.e. if keyed, use that, else for lack of key, use Arrival order. And SEU honors the key similarly, so the pre-collating by the sequence number occurs as an effect of the open\read, so the uncollated physical data appears collated; when the data is saved from the Exit\Save panel, the physical order will since reflect the logical [keyed access path] order.