× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



CRTDUPOBJ requires a higher level of file lock to duplicate a file than
does CPYF. I have been able to CPYF a file when CRTDUPOBJ would not get
started. If you're copying a "seed" file this may not be a concern.

Steve

- -
Steven Morrison
Fidelity Express
903-885-1283 ext. 292




"James H. H. Lampert" <jamesl@xxxxxxxxxxxxxxxxx>
Sent by: midrange-l-bounces@xxxxxxxxxxxx
05/07/2009 10:45 AM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>


To
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
cc

Subject
CPYF vs. CRTDUPOBJ






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. 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?

2) Which option is faster?

3) I know empirically that an OVRDBF will trump any qualification on a
CPYF; what about CRTDUPOBJ?

--
JHHL

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.