When dynamic calls are coded with variables it is difficult to identify all of the main routines that should be tested when a subroutine is modified. If you have good reason to be confident that all of the effected main routines will be tested each time a load module subroutine is updated then dynamic calls and generating NCAL load modules all of the time could be worth considering.
Under the worst case scenario for converting to static calls, I think everything may need to be regenerated, plus revised or new processors and processor groups and types, and maybe new libraries, for example .load instead of .loadlib, which also requires changing JCL The details of how to get from here to there, and what, if anything, can remain as is, depends on the interdependencies and other details of your context. By defining types whose processors always generate object modules from source code, and another type whose processor always inputs object modules and outputs load modules, you can *gaurantee* that the type sequencing will be correct for statically linked load modules, while also supporting dynamic calls if they are still sometimes needed.
The example processors provided by CA are not always good. They may, for example, include processors that input from the same library that it outputs to. For type sequencing it is best to avoid same library as both input and output, within a single processor and across different processors of the same type or different types with the same type sequence priority. Types COBOL and COBOLSUB with NODYNAM may be a feasible compromise, but NODYNAM is only possible with COBOL. Type ASM and ASMSUB, etc., for technical reasons, IMO, will not work well, especially if you activate duplicate blocking.