Z Understand to process PL/I modules even if there is any missing include

We are using Z Understand 3.0.0 from Bob Premium Package for Z, and we have PL/I application code. When we load the PLI code to the Z Understand and we perform a Build, it executes a PLI precompiler/scanner, and after the build has completed, we find that some of the PLI modules that were loaded into ZU have been discarded and have been not built because they refer to some includes that have not been loaded into ZU, in order words, a PLI module is not processed if there is any missing include. So at the end we have a ZU built where some modules are completely missed, and we get not information at all about them in ZU. We see this behavior in ZU 3.0.0 of Bob PPZ, and we also suffered it on previous ZU releases of WCA4Z.

We need that ZU processes those PLI modules with the available info, even if the information is not complete. We STRONGLY prefer to have partial info in ZU about those modules rather than having NONE information at all about them. Of course ZU build process should still raise a warning indicating that there are some missing includes and hence the information is partial. We do not need this to be the default way of work, for us it is OK if ZU provides us a configuration parameter where we can say that we prefer to get the PLI modules built even if there is any missing include; whatever suits IBM development team best,

Of course, the best practice is always to load every include, and this way we would always have complete builds for all PLI modules but, sometimes it is NOT possible to have all the existing includes. For example, in our shop, we have our application code distributed into different Application Units, each of them is owned by different application teams, and people from one application do not have access to all the code from other applications, so sometimes is not posible to have all includes if any of those includes belong to a different application.

Note: the behavior we are requesting in ZU for PLI is the one by default for Cobol; in other words, we want to have the same behavior for PLI than for Cobol. We understand that, as languages,  PLI is different than Cobol , so the internals on how ZU manages them might be different but, we see no reason why this specific behavior would not be feasible to be implemented.