On Jan 15, 2008, at 11:16 AM, Dave Kopischke wrote:
On Tue, 15 Jan 2008 11:05:40 -0600, McKown, John wrote:
Yes, I just didn't really see how EQUALS applies to a MERGE. Possibly
just lact of understanding on my part. I do understand how EQUALS
applies to SORT since SORT is only reading one input file, so
which is
"first" makes sense to me. But MERGE is reading records from multiple
input files, so which is "first"? The first one actually read? (that
would be random, depending on the data in the various input files) Or
the one which is read from the lowest numbered SORTINnn? In the
words of
Vinnie Barbarino "I'm so confused!"
SORT can also process a concatenation, so it can be more than one
input file.
It might even be able to access multiple DD's, but I didn't crack
the manuals
to look this one up. I always thought EQUALS was still valid on a
MERGE, so I
pulled the manual...
I have not done a merge in *YEARS*, having said that I believe (even
if you concatenate) each concatenation has to be in a "higher"
sequence than the file ahead of the concatenation (all records still
must be in the right sequence) so (if) you can concatenate the
records must be in sequence. I hope I said that right and Walt can
correct if I am wrong.
ie sortin01 dd (seq01-09) example for illustrative purposes only
dd (seq10-15) " "
dd (seq16-??) " "
"When specified for a MERGE application, EQUALS guarantees that
whenever
equal-keyed records appear in different SORTIN data sets, the
record from the
lowest numbered SORTINnn will be written first to the output file."
Ed
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
