Perhaps a moderator will move this topic to Cobol.
Generally speaking, when the "key" term is used in our trade, the "key" is located at a fixed position in a record and it has a fixed length. What you want to do is search an entire record for your text. There's nothing wrong with that, but it is usually much slower than doing a compare at a fixed position, and it's worse for you because you want to test multiple "keys" for each record, and you may find yourself reading the entire "flat file 2" to check for your keys only to abandon the process.
You might be better off if you do the key search as part of your copy and then do something to delete the copy if there is no key match. If your shop uses the CA-1 tape management product, for example, you can define the copy as being catalog controlled, and delete the catalog entry for the copy if there is no key match. In a day or two, CA-1 will cycle the tape into the scratch tape pool. I think you can do something similar with the IBM RMM tape management product, but I don't know the mechanics. Talk to your support people to discuss the mechanics for the tape management product your shop uses.
The key (and I'm using the generic meaning here) to what you really want to do depends on the size of the dataset, how often the copy is not done because of a failure to match a key, and how deep you must read the source file before you match a key.