×
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.
On 25-Aug-2014 12:45 -0500, Bill Howie wrote:
<<SNIP>> Hopefully this isn't completely confusing.
I did find the scenario description to be confusing. But I infer the
overall issue is that the created\copied files should exist only *if*
the desired\selected data was found.? The explicit mention of the
Include Records By Field Test (INCREL) parameter seems probably not to
be germane; given that parameter happens to be the source of a great
number of [other data-related] difficulties, knowing only that the
data-copy request is selective [versus what achieves the selectivity]
may be the most appropriate level of detail for that particular scenario.
The Copy File (CPYF) utility copies data and optionally creates a
file [according to Create File (CRTFILE) specification of *YES] for that
specific data-copy request, irrespective the existence of any data being
selected\filtered from the specified From File (FROMFILE). Thus even if
no data was copied, a target file.mbr will be created; given the copy
did not fail for any other reason. There is no special value on the
CRTFILE parameter that suggests to the utility "only if there is data
that would be copied" :-(
The completion message that records the number of records copied to
the target file.mbr could be reviewed, or a review of the number of
[additional] records for the target member [e.g. per Retrieve Member
Description (RTVMBRD) for Number Of Current Records (NBRCURRCD)] might
be used, to infer the effect of the copy request [taking into
consideration any possible effects from concurrent activity, e.g. by
preventing any concurrency albeit effectively impossible in that
scenario]. If the effect was verified to be _no records copied_ then
the program would have learned that [the existing target-file member or]
the created file and member are not desired and thus perhaps should be
_deleted_ [e.g. Delete File (DLTF) or Remove Member (RMVM)] as a
reactive procedure]. Of course a proactive test for the existence of
the data, by performing the chosen selection prior to invoking the CPYF,
would seem duplicitous.
Any input would be much appreciated.
I would probably code the solution entirely in SQL using the System
Database Cross-Reference (DBXREF) files (QADB* in QSYS) as the basis for
the /file/ and /field/ information; the SQL catalog VIEW files such as
SYSTABLES and SYSCOLUMNS may suffice in that regard [verify the WHERE
clause to be sure the required data will be included], as they are built
over the *DBXREF data. The SQL has the advantage of being able to
operate with isolation-level [whereas CPYF does not] and other issues
with potential concurrency are more easily solved. And if there is any
relevance to the use of the INCREL() of CPYF, then the use of SQL
instead, is a much better choice; switching to SQL is often an option
chosen to deal with the undesirable effects from trying to use the
INCREL feature. If performing the /copy/ work is done under isolation,
then after an effective /copy/ request whereby no data was inserted, the
next request against the TABLE previously created, would be to DROP
TABLE, such that when the overall work completed the effect of the
COMMIT would be that the empty file would no longer exist.
midrange.com
