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:
<<SNIP>> I guess I'm still interested in the use case that suggested
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
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.
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
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.