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.