When developing on IBM i, the CRTSQLRPGI command is essential for incorporating SQL statements into your RPG programs. However, a commonly overlooked detail can lead to hard-to-diagnose compilation failures: the handling of compilation directives.

Understanding the CRTSQLRPGI Process

By default, the SQL precompiler scans your source code, identifies SQL statements, and inserts the necessary RPG code to execute them. After this step, the updated source is passed to the ILE RPG compiler for final processing.

However, the SQL precompiler does not interpret compilation directives such as /COPY, /INCLUDE, /DEFINE, or /IF. This can be problematic if your program relies on these directives to declare variables or include code.

As a result, you may encounter common errors such as:

• RNF7030: The name or indicator is not defined.
• RNF7503: The expression contains an operand that is not defined.

The Solution: RPGPPOPT(*LVL2)

To avoid these errors, simply specify the *RPGPPOPT(LVL2) option in your CRTSQLRPGI command. This option tells the ILE RPG compiler to process compilation directives before the SQL precompiler steps in. As a result, all variables required for your SQL statements are properly defined and available.

Why Switch to RPGPPOPT(*LVL2)?

The current default value of RPGPPOPT is *NONE, but there are no drawbacks to using *LVL2. This setting ensures that all your compilation directives are correctly interpreted, eliminating potential errors caused by undefined variables.

You can even set this option as the default in your automated build processes: https://www.ibm.com/support/pages/resolving-crtsqlrpgi-fails-rnf7030rnf7503-using-rpgppoptlvl2

Let's try a compilation with the RPGPPOPT option set to *NONE.

This will result in an error indicating that the NOMPRO variable is not defined.

Now let's try it with the RPGPPOPT option at *LVL2

Compilation passes and the program runs

It is a good idea ... as long as you are not working with compiler directives that include/exclude source code.

We are working with References (Reference Files and especially with complex data structures and array data structures). All references are conditioned with compiler directives.

To always have all references we include special copy members automatically in all sources and prototype copy members. It works great as well with pure RPG and embedded SQL.

When using *LVL1 or *LVL2 the copy members are physicall copied into the temporary source members without considering any compiler directives and after compilation runs. This blowed up our source code so we finally could no longer compile (with *LVL2)

When developing on IBM i, the CRTSQLRPGI command is essential for incorporating SQL statements into your RPG programs. However, a commonly overlooked detail can lead to hard-to-diagnose compilation failures: the handling of compilation directives.

Understanding the CRTSQLRPGI Process

By default, the SQL precompiler scans your source code, identifies SQL statements, and inserts the necessary RPG code to execute them. After this step, the updated source is passed to the ILE RPG compiler for final processing.

However, the SQL precompiler does not interpret compilation directives such as /COPY, /INCLUDE, /DEFINE, or /IF. This can be problematic if your program relies on these directives to declare variables or include code.

As a result, you may encounter common errors such as:

• RNF7030: The name or indicator is not defined.
• RNF7503: The expression contains an operand that is not defined.

The Solution: RPGPPOPT(*LVL2)

To avoid these errors, simply specify the *RPGPPOPT(LVL2) option in your CRTSQLRPGI command. This option tells the ILE RPG compiler to process compilation directives before the SQL precompiler steps in. As a result, all variables required for your SQL statements are properly defined and available.

Why Switch to RPGPPOPT(*LVL2)?

The current default value of RPGPPOPT is *NONE, but there are no drawbacks to using *LVL2. This setting ensures that all your compilation directives are correctly interpreted, eliminating potential errors caused by undefined variables.

You can even set this option as the default in your automated build processes: https://www.ibm.com/support/pages/resolving-crtsqlrpgi-fails-rnf7030rnf7503-using-rpgppoptlvl2

Let's try a compilation with the RPGPPOPT option set to *NONE.

This will result in an error indicating that the NOMPRO variable is not defined.

Now let's try it with the RPGPPOPT option at *LVL2

Compilation passes and the program runs

If you have some copy files that should be seen by the SQL precompiler and you have other copy files that should wait until the final compile

• Use /COPY for the copy files that should be seen by the SQL precompiler
• Use /INCLUDE for the copy files that should wait until the final compile
• Use RPGPPOPT(*LVL1) so that your /IF and /ENDIF will get processed 

*LVL1 only handles /COPY directives during the initial processing of the source by the RPG compiler. The SQL precompiler ignores the /INCLUDE directive. So with *LVL1, the final processing of the /INCLUDE directive waits until after the SQL precompiler has processed the source.

It is a good idea ... as long as you are not working with compiler directives that include/exclude source code.

We are working with References (Reference Files and especially with complex data structures and array data structures). All references are conditioned with compiler directives.

To always have all references we include special copy members automatically in all sources and prototype copy members. It works great as well with pure RPG and embedded SQL.

When using *LVL1 or *LVL2 the copy members are physicall copied into the temporary source members without considering any compiler directives and after compilation runs. This blowed up our source code so we finally could no longer compile (with *LVL2)

When developing on IBM i, the CRTSQLRPGI command is essential for incorporating SQL statements into your RPG programs. However, a commonly overlooked detail can lead to hard-to-diagnose compilation failures: the handling of compilation directives.

Understanding the CRTSQLRPGI Process

By default, the SQL precompiler scans your source code, identifies SQL statements, and inserts the necessary RPG code to execute them. After this step, the updated source is passed to the ILE RPG compiler for final processing.

However, the SQL precompiler does not interpret compilation directives such as /COPY, /INCLUDE, /DEFINE, or /IF. This can be problematic if your program relies on these directives to declare variables or include code.

As a result, you may encounter common errors such as:

• RNF7030: The name or indicator is not defined.
• RNF7503: The expression contains an operand that is not defined.

The Solution: RPGPPOPT(*LVL2)

To avoid these errors, simply specify the *RPGPPOPT(LVL2) option in your CRTSQLRPGI command. This option tells the ILE RPG compiler to process compilation directives before the SQL precompiler steps in. As a result, all variables required for your SQL statements are properly defined and available.

Why Switch to RPGPPOPT(*LVL2)?

The current default value of RPGPPOPT is *NONE, but there are no drawbacks to using *LVL2. This setting ensures that all your compilation directives are correctly interpreted, eliminating potential errors caused by undefined variables.

You can even set this option as the default in your automated build processes: https://www.ibm.com/support/pages/resolving-crtsqlrpgi-fails-rnf7030rnf7503-using-rpgppoptlvl2

Let's try a compilation with the RPGPPOPT option set to *NONE.

This will result in an error indicating that the NOMPRO variable is not defined.

Now let's try it with the RPGPPOPT option at *LVL2

Compilation passes and the program runs