John Candidi wrote:
So, I guess the logical needs to be redefined that we have
already from the sounds of it
CRPence wrote:
John Candidi wrote:
How do you add an index to fields in a physical file which
was defined in COBOL without recreating the file?
Presumably "defined in COBOL" means the file
declared\referenced in\by the COBOL; i.e. an externally
described PF was created using SQL or DDS. In that case, then
either of ADDPFCST CL command or the ALTER TABLE ADD CONSTRAINT
SQL statement, to add either a PRIMARY KEY constraint or a
UNIQUE constraint would suffice; note: these require MAXMBRS(1)
for the physical, if it was created using CRTPF.
I am not sure how my reply would lead one to that presumptive ["I
guess"] conclusion ["needs to be"]; not without specific details.
From where I sit, this discussion is all too nebulous.
A difficulty for me was originally, and remains, with the use of
"defined"; now again, with "redefined". The definitional attributes
of a file can be changed [redefined in this sense?], even if only by
first delete and then create; i.e. as an object-based OS, for lack
of a /change/ or an /alter/ feature to change definitional details
of [recompile] an object, rather than simply changing general object
attributes. Whether a program needs to be recompiled due to a
change in the keys, may depend on the language. However there is
_also_ how a file is /defined/ to the program. A program likely
needs to recompile to change how it /defines/ [declares?] the file,
even if the definitional attributes of the file remain unchanged;
i.e. as a file is /defined/ with respect to and for use by a program.
Not really wanting a definition of /defined/, simplified examples
tend to provide better context to explain\clarify the specifics of
an inquiry, in order that a response might be better directed.
Maybe I am just being thick, but even with the other post explaining
that the program is already using a LF, or maybe actually _because_
of that comment in the other post, the intent of the original
inquiry is still only as /clear as mud/ to me.
I think I now understand one aspect however, that there is a goal
to improve the performance of the program currently accessing a LF;
as inferred from the other post stating an apparent desire to "speed
up the processing time for something reading that file". I did give
reply with some comments directly, very generically however, for not
knowing what the program declares, does [read entire file, subset,
update or read-only], nor the file(s) and definitions, nor what
specific /redefining/ is presumed might be worthwhile. What is
being done with the file.data by the program, and what is desired
[other than better speed of processing], are all still too vague.
If the desired key can not be unique, then the best option [to
avoid re-creating the PF with the desired key fields] is to
create and then use a keyed LF over the PF; created either by
DDS with CRTLF or SQL CREATE INDEX SQL statement. I prefer to
use the LF approach anyhow, to use only constraints for any
keys in a physical.
I did forget to add mention to an available but less preferable
method of change, in the part of my reply just above: The request
to CHGPF SRCFILE() against a DDS created physical can be used to
add, change, or remove the keys; i.e. add, change, or remove the
K-specs [and add\rmv UNIQUE kwd] in the DDS source, then issue the
CHGPF which was created with the prior version of that DDS source.
Certain limitations or restrictions may apply; e.g. DLTDEPLF. The
file is in fact actually re-created and the data copied, even though
appearing as just the one act of /change/ to the file, from the
perspective of the requester. So figuratively the change is
effected "without recreating the file", but literally the change is
effected by recreating the file.
Regards, Chuck
midrange.com
