× 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?


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.