Compilable?

The code base I am using for testing ABL2DB has a bunch of bits and pieces which date back to the mid-80s.  Some of them are no longer referred to by any real application code, but they are there in the filesystem and so get picked up in the ABL2DB scans.  Given the Varnet base, there are files with no extension which are .ps so I have switches that will allow ABL2DB to consider anything without an extension as a possible compile unit.  Unfortunately, there are also some include files without extensions ... not sure how that happened.  So, what I do is to collect a list of files that look like they might be compile units (.p, .w, .cls, and no extension) and then try to compile them, expecting that a number of them will not compile because they are includes or fragments or reference stuff that isn't there any more, etc.  So, in the ABL2DB database, every disk file has a flag to indicate whether it is or is not compilable.  I set that flag based on whether or not there is a .r corresponding to the disk file.

So, tracking down an error report from a new piece that is scanning for shared variables, I get these two files which Proparse has trouble with.  I look at the files and it doesn't surprise me that Proparse is having trouble because this is what the top of the file looks like:

/* lib/secr/cansee   Test if user can see value of a field with password
                 Sept 1989
                {1} = field name
                {2} = logical variable to return yes/no - ok to display
Assumes the inclusion in the calling program of:
 variable wpassword like z_pass.password.
*/
{2} = false.
find z_pass where
    z_pass.funct-name = functionname and
    z_pass.field-name = "{1}"

and, sure enough, where Proparse complains is line 8 "{2} = false."  So, no fault to Proparse, but why is this file even being processed?  I check the database and yes it is flagged compilable.  I check the filesystem and sure enough there is a .r and a listing and xref files.  The listing is truncated where the code sample above is, even though there are 40 lines in the file.

So, why does this produce a .r?   And, can anyone think of a test besides the existence of the .r to tell if it should be analyzed by things looking for compile units.

The only thing that occurs to me is to notice that it is flagged as both compilable and as an include, which should make me suspicious, but I don't know that some people wouldn't have a code base where that was true.

Ideas?

Note, as things stand, the compile pass occurs prior to building the table of diskfiles.  I did report errors in the compile, so if I built the diskfile DB first, then I could not flag as compilable anything that had errors, but that is going to take some restructuring.   And, this is only 2 files out of nearly 4400 that have the issue.