in reply to ISOLATE 2 ASSOCIATED FIELDS IN A TEXT FILE, then CONVERT the first into another based on a table of definitions

I think you will find it of enormous help if you consider what kind of report output(s) you want or what kind of queries will need to be run on this merged version of your two files. Meaning write the user spec of what this will do from a "black box" perspective. A clear understanding of where you want to end up will drive the techniques and structures leading to this result. In other words, the problem is easier if we know where we want to wind up.

Update: Already we have a couple of proposed solutions from bichonfrise74and Bloodnok. The one from bichonfrise74 is organized to make accessing the CGxxx stuff easy. The one from Bloodnok is organized to make accessing the NM_xxx stuff easy. The real question is what best suits your need? It could well be that "none of the above" is the right answer.

another Update: One important thing in an user spec is what to do when "things don't work". You probably have noticed that the critical user data that links the your files doesn't match. So what do you want to do about that? bichonfrise74 ignores those records while Bloodnok generates a data struct with an erroneous value for the last thing when the $NM value is bogus, although it reports that $NM value is undefined. These are the types of things that need to be planned in advance.

  • Comment on Re: ISOLATE 2 ASSOCIATED FIELDS IN A TEXT FILE, then CONVERT the first into another based on a table of definitions