Joined: 06 Jun 2008 Posts: 8214 Location: Dubuque, Iowa, USA
Without sorting file one, unless it is pretty small, you've got problems. Sort the file and it is a two-file match, for which there's a sticky. Are the duplicates in file 1 together, or are the duplicates scattered throughout the file?
If the duplicates occur together, you could create an indexed file from file 2, read a record from file 1, retain its key for duplicate checking, directly read file 2 to see if the record is there, update file 2 to flag the record as being processed, and output to file 3. After all records in file 1 have been processed, you sequentially process file 2 one time and output to file 4 all records that do not have the flag set.
If the duplicates occur throughout the file, you probably cannot process file 1 successfully unless it is small enough to stay in memory. If file one is small enough, you could build a table in memory of the records and sort it by key, then do the comparisons with file 2.
Joined: 23 Nov 2006 Posts: 19270 Location: Inside the Matrix
I am not supposed to sort my first input file one on emp-key (28 bytes),
Sorry to sound harsh, but what in the world determined this "requirement". . . The original file may need to be left in the current sequence, but that should not preclude sorting a copy to use for this match process.
There have been people who posted topics who tried to match files without the files being in sequence and found the job would never end (well not for many days anyway).
Is there any possibility to code this in COBOL.
Of course. As mentioned before, there is a "Sticky" near the top of the cobol forum that provides the exact code you need. Both input files must be in sequence. . .
Joined: 28 Nov 2006 Posts: 305 Location: Deerfield IL
This design makes sense and is efficient if file 1 is very large and file 2 is small. Read file 2 and load it into a table in working storage. Then read through file 1 doing a table (search) lookup for each record. This can be done in either COBOL or Easytrieve.