Okay, first of all, I had overlooked ... :*{ ... SAS::Parser.   Mea culpa on that one.

One thing that I know we’ll be doing is looking at the SQL statements that are issued.   Sometimes we are looking in a mixture of in-line code of different types.   (Over the years, many now long-gone programmers did things in different ways.)

The general notion that I have right now is that ... “somewhere in all this unpredictable mess is a particular string (of tokens) that I am looking for.” When and if I find it, I know that “this thing” has the following general structure, which I would now like to parse.   And, when I do parse it, I want to look for particular things and ignore the rest.

One strategy, of course, is to use regular expressions or what-not to carve out chunks of source-code that can then be subjected to a regular parser.   But there are two elements to that approach which give me pause:

1. “Now I am writing, and maintaining, two sets of code that are jointly responsible for handling the file.
2. Within each isolated chunk of code that I want to parse, I still fear that I would have to provide complete-and-correct grammar information.

So, from a parsing point-of-view, it is rather like looking for the good-stuff in a file chock-full of “syntax errors.”

(Kind of like the Gary Larson cartoon about “what a dog actually hears” ... blah blah blah blah dog food blah blah blah play catch blah blah blah ...   I want to be able to tell the computer about dog-food and games; about what I am truly interested in and nothing else.)