Any change made to source code can conflict with either the user selected COBOL dialect or data names. With care, any potential problems can easily be avoided.
If the user code conforms to a dialect that does not support features that the preprocessor needs to make use of, there are two issues to be overcome. Firstly, non-conforming code would be flagged; secondly the required reserved words might not be in the dictionary.
In order to overcome the problem of flagging, no lines that are inserted by a preprocessor are ever flagged by the Compiler. To make all required reserved words available, a preprocessor could generate a $SET statement to specify, for example, the ANS85 directive.
However, this would have some unwelcome side-effects: the behavior of some statements would be changed, and valid data names would be rejected as they would now be reserved words instead.
A better technique would be to determine which words are actually needed and selectively add only these using the ADDRSV directive. For example, if only the reserved word FUNCTION is needed, it can be added using the ADDRSV(FUNCTION) directive. This, however, would still causes problems if the user code declared FUNCTION as a data name, and the best solution of all is to use the ADDSYN directive, and chose an alternative word to FUNCTION that is unlikely to be used by the user.
For example, generate the directive ADDSYN "FUNCTION" = "PREPGEN--FUNCTION" and thereafter use PREPGEN--FUNCTION instead of FUNCTION when generating code.
If a preprocessor needs to create data for its own use, it should chose names that are unlikely to conflict with user chosen names. As in the case above, selecting a name like PREPGEN--USERID is unlikely to conflict with a user selected name, but USERID alone might well cause problems.
UNIX is case-sensitive. In your call statements, you need to use the correct case. For example, a CALL (XXX) statement results in a RTS173 error if the program is named xxx.cbl.