James H. H. Lampert wrote:
One of our applications requires one or more workfiles
in QTEMP. Currently, those workfiles are created by
CPYFing an empty "seed" version of the file located in
the application directory.
Yesterday, we discovered that a long-unexplained
intermittent glitch was a side effect of an OVRDBF,
which caused workfiles to be copied from an existing
(and non-empty) copy in QTEMP, instead of from the
empty "seed" file.
I've put in a remedy (rearranging things to CLRPFM the
workfile even if it's freshly generated, instead of only
doing it if it had already been used in the job), but I
see that CRTDUPOBJ (unlike CPYF) has the ability to
create a guaranteed-empty copy of a file.
The CLRPFM is often a chosen method for utilities that might
re-run multiple times and purposely do not DLTF since the last run
to avoid the overhead of creating\deleting /objects/ versus only
data. Similarly for when a prior invocation failed, but did not get
to perform a coded DLTF or CLRPFM. Given the complexity of the
database file objects, avoiding the crt\dlt activity is much more
important for database *FILE; replace the data, not the file and\or
member.
Obviously, this would be the more elegant solution,
but it raises some questions:
1) Does copying a file into QTEMP with a CRTDUPOBJ
potentially raise any authority issues that doing it
with a CPYF doesn't?
The *OBJMGT right is required to be adopted or on the file being
copied for CRTDUPOBJ to be allowed to the authorized user.
The CPYF attempts to mimic CRTDUPOBJ for authority; i.e. the
FROMFILE() defines the TOFILE() authority for CRTFILE(*YES)
requests. That design was a flaw, since it is literally impossible
to effect that generally, because the CPYF does a very different
function; e.g. CRTDUPOBJ can not create a PF from an LF like CPYF
can. IMO the CPYF command should have an AUT() parameter added to
give choice. I recall there is at least one unresolved APAR for
authorities, but it was probably somewhat odd; possibly even a
failure case. I doubt you would find any difference for authority
in most simple & typical cases.
The bigger issue is for triggers and constraints, which the
CRTDUPOBJ gives parameters TRG() and CST() parameters to enable
their exclusion to better mimic the CPYF.
2) Which option is faster?
The CPYF can be the fastest, as it may use the exact same program
that CRTDUPOBJ uses for copying the data. Copying an empty physical
file with one member with no constraints or triggers however, it
will be a wash. The CPYF does have negatives that I would prefer to
avoid, some resolved [e.g. an SQL TABLE as FROMFILE() does create a
TABLE, at least in most cases, IIRC], for which I find CRTDUPOBJ the
most appropriate except when there is a specific need to get partial
data.... but even then, I would rather use CREATE TABLE [AS] and
SELECT to choose the data for insert.
3) I know empirically that an OVRDBF will trump any
qualification on a CPYF; what about CRTDUPOBJ?
OVRDBF establishes an override to the behavior of common data
management open. CRTDUPOBJ does not open the file, and has no
additional [extra open] support for overrides. CRTDUPOBJ is
generally used to create the empty copy from a /model file/; i.e.
how most OUTPUT(*OUTFILE) of fixed-format output file support works.
This design also depends on overrides having no effect. This
implementation matches with the purpose described in this message.
Regards, Chuck
midrange.com
