On 06-May-2014 08:36 -0500, rob@xxxxxxxxx wrote:
How comfortable are you with SQL? And creating UDFs? We've created a
function called QCMDEXC.

So, with a output file of DSPOBJD of both libraries,

select a.odobnm, a.odlbnm, a.odobtp
, qcmdexc('CRTDUPOBJ .... concat ... )
from aliboutput a left outer join bliboutput b...
where ....check dates, etc here...
order by 1

the ORDER BY ensures the command performs all the
QCMDEXC instead of stopping at the screen full

If the "stopping at the screen full" is an allusion to the effects of a query being run in an interactive SQL session output to the display, solely the specification of an ORDER BY is _insufficient_ to guarantee a query runs to completion. The Start SQL (STRSQL) session attributes must include _both_ REFRESH(*FORWARD) and either the positioning request *BOT [or B] for "bottom" or paging to the EOF is required. Without both of those in effect, an interactive session should never be utilized to effect external action. Note: Paging to the bottom with the Refresh option set to *ALWAYS would likely perform the UDF multiple times for data near the bottom [and the top for few rows].

The results of such a query might best be processed in FETCH statements anyhow, to deal with negative feedback from the UDF on a per-row [i.e. per Object] basis.

p.s. Database file members may be viewed as effective [and are actually internal] /objects/ so there may be value in treating them as objects in such an application; of course the OP clarifies "No PF or LF to be concerned with" in their specific scenario. Anyhow, if DSPOBJD output files were used, the DSPFD for *MBR or *MBRLIST data would be analogous for the DBFs.

This thread ...


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