×
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.
If no sort specification is given for the FMTDTA request, then data
will still be combined, but I have never read the rules for ordering
without sort; for relational access, order would be undefined. I
suppose it might be defined to always effect arrival order with no sort
specification; in a simple test, that was my result -- verify from the
documentation what specifically occurs for no sort spec.
FMTDTA is merely *a* way to easily effect a union of data, but into a
copy, instead of the data being available in one ODP. The copy however
can limit the columns; the noted CRTPF could reflect a definition which
limits the amount of data copied if the called program could deal with
that. The field specifications in the SRCMBR of the FMTDTA define what
byte-columns of data to copy.
What IMO would be considered *the* way to effect that union would be
the CRTLF and then ADDLFM specifying which PFM to access. If the LFM
could be algorithmically named, then they could be left for use rather
than added and removed which is at least somewhat expensive; much more
so if keyed. AFaIK the OPNQRYF does not provide any UNION capability,
but that would be the dynamic way for a run-time ODP if it did.
The SQL UNION _would_ be *the* way, but that is available only at
runtime using the overrides, and thus requires the SQLCBL instead -- or
like with FMTDTA, it could create a temporary copy. Since the SQL does
not support multi-member files except by override or ALIAS, and since
overrides are available only at run-time and the ALIAS is not available
to be used in a CREATE VIEW, SQL is probably not as good a choice here
if a goal is to limit code changes.
If the data sets are small and the CLP is already there, then FMTDTA
seems a good fit. If the temporary copy is identical in format to the
original then the program may be happy/unchanged with just that and the
override.
If all work is currently in the CBL program, such that the CLP would
be new, then changing the CBL to SQLCBL and adding a CREATE GLOBAL
TEMPORARY TABLE AS SELECT ... UNION ALL ... [in a module if ILE] might
be a better option. Especially if the data sets may be large and keyed
selection can limit the data by rows, and the column list can limit the
fields that the COBOL READ requires. Or even better, rid the temporary
copy and just FETCH INTO the variables directly. Seems like a good
excuse for a foray into SQL if it fits.
Regards, Chuck
-- All comments provided "as is" with no warranties of any kind whatsoever.
Michael Rosinger wrote:
"CRPence" <crp@xxxxxxxxxxxxxxxxxxxx> wrote in message
news:mailman.6365.1179765973.13580.midrange-l@xxxxxxxxxxxxxxx
If a temporary sorted copy of the data is acceptabl, perhaps:
crtpf qtemp/jobparmx srcfile(srclib/ddssrcf) srcmbr(jobparms)
mbr(tempdata) size( ) ...
...
/* clrpfm qtemp/jobparmx mbr(tempdata) -- implicit in fmtdta.? */
FMTDTA INFILE((MNR/JOBPARMS DMS200_100) (MNR/JOBPARMS DMS200_ALL))
OUTFILE(QTEMP/JOBPARMX) SRCFILE(srclib/ddssrcf) SRCMBR(JOBPARMF)
ovrdbf PARMS TOFILE(QTEMP/JOBPARMX) MBR(tempdata)
call pgm(dms200)
...
Chuck,
In most cases, sorting of the individual member records is not necessary but
the order of the concatenated members could possibly be important. I suppose
FMTDTA could work. Is there an option where I could simply concatenate 2 or
more physical file members in the order I specify?
Is FMTDTA *the* way to concatenate or merge files on the iSeries?
midrange.com
