• Separation of source compilation and module binding steps (providing linkage to other ILE languages)
• Addition of built-in functions (BIFs), which provide continued language extension
• Introduction of smaller bindable units with subprocedures (not limited to just program-level calls)
• Comprehensive pointer manipulation support (two types of pointers: a generic data pointer and a procedure pointer)
• Dynamic (runtime) memory allocation on free store
• Data type support for short, regular, and long integers, both signed and unsigned; floats and doubles; pointers; and Java objects
• Bit manipulation with XOR, AND, and OR BIFs (V5R2)
• Abstract Data Type (ADT) support--like structs in C
• Arguments passed to functions either by reference (lacking from C) or by value
• Free-form language expression for program logic (calc specs), but data specifications remain fixed (which is fine since data must be structured to be usable)
• Better interoperability with Java--raw Java Native Interface (JNI) required for C
• Conditional compiler directives
• Thread safety (same as C)
• Language-dependent or -independent error handling

Those are just a few of the advantages ILE RPG IV (as of V5R2) added to the programmer's arsenal to combat the fluid nature of computing requirements in today's environment. And you must not forget that anything C can bind with, RPG can bind with as well. For example, before RPG had the capability to convert character data to numeric, you could use C's atoi() and atof() functions to accomplish that objective. On a recent project, I avoided completely rewriting a file editing application (a DBU-like utility) by replacing RPG I/O operations with equivalent C I/O functions. This was required because RPG does not provide the runtime null field support for program-described files (which is what you must do to achieve dynamic file maintenance in RPG) that can be accomplished in C. While this was not a trivial task, it was not difficult either. (Watch for a future MCMagOnline article entitled "How Could Life Be Better?" for an example of this.)

A Better View

By way of example, Figure 1 shows a functional code snippet that uses C's printf(), prototyped in [B], where you might have previously used the DSPLY opcode to list address information from two variables (var1 and var2 shown at [D]) created from the ADT address [A].

Figure 1: Use C's printf() where you might have previously used the DSPLY opcode.

Yet printf() is a better solution because you can format the output better than with DSPLY, and you can scroll to see previous output produced from using the printf statement. The printf function is defined in C as a variable-arguments function, which is indicated by the ellipses (...) shown in the following C prototype:

However, since RPG IV cannot define such a function, you can emulate this functionality by prototyping multiple versions of the printf function, all bound to the same C printf binary but with different prototype names. When creating your own prototypes for printf required by your application, the only requirement is that the first argument be defined as a pointer to a null-terminated string (referred as the format-string argument, i.e., containing format conversion identifiers like %s,%c,%d,%f, etc.). A list of these format conversion identifiers are shown in a table in the printf() documentation in the ILE C/C++ Run-Time Library Reference). Every argument following the first can be any valid data type defined in C (e.g., integer, float, double, etc.). This will accommodate most requirements for debugging your applications.

An example of this is shown in [B] of Figure 1 where the printf2 function takes an integer argument after the initial string argument to print the total number of addresses defined from the ADT address. This calculation immediately follows the ZIP code initialization for each address variable and is printed as the last and only output line printed by the printf2 prototyped variation of the printf C function as shown in [F] of Figure 1.

The Great Escape

The C shell output window is invoked to display the results of printf when the activation group is set to *new. You should be aware that since RPG does not invoke the C precompiler, escape sequence characters like ' ' (new line or linefeed), ' ' (tab), etc. are not translated to their equivalent hex values. (For a complete list of escape sequence characters, refer to Escape Sequences and Appendix A-AS/400 Control Characters in the ILE C Language Reference.) For this reason, the newline standalone variable shown in [C] was defined with a value of x'25' (x'15' if using *IFSIO) to enable a linefeed after outputting the results. You will need to do the same for any other escape sequence characters you wish to embed in the output. This is a small price to pay for the superior output achieved using printf(). Displaying the data in the variables (var1, var2) is a simple matter of using the identical qualifying dot (.) notation used in C to access structure data members as shown in [E] of Figure 1. The "%s" notation in the formatted output string is used to print the string data of var1.name and is a standard C formatter character.

Like DSPLY, the printf function can be handy for debugging your applications.

Note that even though Figure 1 presents the use of printf() in free-form expressions, you can also use it in fixed-form expressions with a CALLP. Note the similarities when all forms of the printf() are put together, as in Figure 2:

Figure 2: You can use printf() in both free-form and fixed-form expressions.

Watch the Gotchas!

There are some noteworthy "gotchas" when mixing C with RPG:

• A single character returned from a C function will be promoted (also called "widening") to an integer of 4 bytes versus the 1 byte expected. The value will be right-justified to appear in the last byte of the integer.
• When a C function calls an RPG IV subprocedure that contains the %parms BIF (that normally seems to work fine when called by another RPG subprocedure), the value returned from that BIF is not what the programmer expects--the number of arguments passed in. The result is always -1 (meaning an error occurred) because RPG always passes a minimal operational descriptor to called functions, while languages like C do not by default, unless specifically directed to. Since the %parms BIF cannot determine the number of arguments passed to the RPGIV subprocedure, use the ILE CEE API CEETSTA instead to get the number of arguments passed to an RPG IV subprocedure when called from C (read the requirements and limitations of this API carefully; they will affect the manner in which arguments are passed and the order of argument definition in the called function).
• Null-terminate strings passed to C functions and remove the null-termination character when a string is returned with the %str BIF.
• Use the ALIGN keyword to align structures (or a pointer to a C structure) passed to a C function or returned when the _Packed keyword has been omitted from the structure definition (in the called C function) to ensure consistent boundary alignment between caller and called function.
• Constant pointers (as in "char * const") are references (think of them as pointers to pointers) to pointer values, not the actual pointer value themselves. As such, they must be de-referenced before used as a based on value for a standalone variable or data structure. (See an example of how to do this in RPG IV in the upcoming article "How Could Life Be Better?")

Some of the Best Tools Are Found in Unlikely Places

If you are an RPG programmer in a shop with C programmers, you have undoubtedly had extensive debates regarding the advantages of C vs. RPG and concluded that it comes down to which language you are most comfortable with and what your corporate strategy is regarding the portability of source. However, if portability is not an issue and you need some features in the standard C library, they come free with OS/400 and you don't need the C compiler to use them. Yet to take advantage of this situation to its fullest benefit, it helps if you learn a few simple C basics to understand how to create the RPG prototypes you will need for the C functions you wish to use. (Unfortunately, IBM has not seen fit to include RPG prototypes in QSYSINC. I hope this changes in the future.) But note that as of V5R1, the C function prototypes previously available only with the licensing of the C language now have a new home in QSYSINC.

The more you use C functions in your daily application requirements, the more C you will learn by default. This could be advantageous if you later wish to learn C++ (or Java), another beautiful language (like RPG IV) that has also been dubbed "a better C than C."

Jim Barnes is a freelance writer and independent consultant working in Houston, Texas. Jim can be reached at This email address is being protected from spambots. You need JavaScript enabled to view it..

References and Related Materials

ILE C for AS/400 Language Reference (SC09-2711-00)