James, I suspect the programs referenced in your compile list are always recompiled because they are encrypted. The following excerpt from our Admin Guide, explains the reasoning behind why we always recompile encrypted programs (and programs that include encrypted programs).

"The incremental compile uses Progress compile XREF files to understand program dependencies, however Progress does not support generating XREF files for encrypted programs. The default configuration will recompile a file if it is encrypted or if it depends on a file that is encrypted. This strict approach to correctness ensures that all source code changes are processed. (Consider an example where the unencrypted program A includes the encrypted file B. We know if A or B has changed, but we do not know that B depends on the changed file C, because we cannot get dependency information for B.)"

To see why a program is recompiled we can execute the compile with a more verbose logging threshold:

yab -log-level:trace -v code-mfg-customizations-update

Can you run that command and post back the results? Also what version of YAB are you on?

yab info | grep yab

So I understand the scenario that you have described with encrypted code.  For sure that is at play.  However, it drives my point of not being able to control precisely what gets compiled.  From an audit perspective the r-code will keep showing a last change date of the last time we did a compile for a new change.  However, nothing was actually changed

Here is the yab version:

yab                                                        1.3.1.0        local

yab-client                                                 1.3.1.0        local

I have the output from the compile with the verbose logging, but it is over 1300 lines.  I do not see a way to attach a text file to this reply.

In the log output we would be looking for messages of the form "Compiling ??? because..." associated with the "OpenEdgeCompileCommand".

One of the overriding principles of YAB is that it should be possible to reproduce the environment at any point in time. With respect to compilation we would like to say that the end state of the system is consistent given a consistent set of inputs. When compiles are driven by per request compile lists the state of the system may depend on the ordering of the compile requests and the end state of the system (r-code) depends not only on the order of the requests but the state of the source code when the request was submitted. Historically this has led to variances between QA environments and production environments. (The same sort of problem occurs when a developer manually compiles code in the Progress editor "off the books".)

With that said, in YAB 1.4 we do provide more fine grained control over the compile to support developer efficiency. We do not recommend that these techniques should be used in production environments. See the "Compile for Developers" topic in our 1.4 Admin Guide:

https://documentlibrary.qad.com/documents/2370665/2370821/ConfigAdmin_AG_YABEE14.pdf