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.

Return to Archive home page | Return to MIDRANGE.COM home page