Re: CPYF vs. CRTDUPOBJ

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