In this, the last article of my series, you will examine some of the current deficiencies in RPG IV, critically evaluate the differences between RPG IV and C, and understand what RPG IV requires to position it as the premier integration language for the iSeries. While C, with its descendent C++, can afford to stay locked at its current level of support, RPG IV does not have that luxury and must continue to improve and evolve to secure the "Integrator" title for the iSeries. This article discloses the most critical areas where RPG IV severely lags behind C and explains why your favorite tool is in need of an evolutional design change and why you should be more concerned with this deficiency than with adding yet another %BIF in the next release. For the complete code for this article, click here.

A Brief Re-visitation...

In "What? RPG IV a Better C Than C?", the first article in this series, you learned the basics of prototyping C functions, using printf() as an example for flexible output results and as a debugging supplement, and you learned about some of the gotchas you may experience when mixing RPG IV with C. In the second, "How Could Life Be Better?", you saw the flexibility gained by using C database I/O functions rather than using the more static behavior of RPG I/O opcodes. Then, in "Interfaces in ILE RPG IV--Finding the Middle Ground", you advanced your technical prowess by discovering the importance of interfaces in object-oriented (OO) languages and by learning how to create similar binding commitments in RPG IV, with a corresponding source example demonstrated in Java. Now, it's time for you to explore what RPG IV requires in order to achieve its full potential and become the premier integration language for the iSeries platform and possibly more.

What Can Your Language Do?

To be competitive as a language that integrates applications written in other languages, a language must provide semantics and advanced programming constructs for such things as abstract data types (ADTs--for example, user-defined data types), free-form algorithmic expression, separate variables storage area and scope resolution for procedures (local variables), full data type support for the range of commonly supported primitive data types, embedded ANSI SQL support (including support for stored procedures and triggers), both automatic and on-demand memory allocation, statically ("strongly") typed pointers and references for both primitive data types and ADTs, interoperability with other languages (both procedural languages and Object-Oriented Programming Languages [OOPLs]), support for all types of binding (static, referential, and dynamic), built-in functionality to convert strings between diverse encoding schemes (supporting cultural language independence), and the ability to bind with APIs that support diverse communications and data exchange protocols and formats (for example, the XML format using the SOAP protocol over TCP/IP).

As noted in "What? RPG IV a Better C Than C?", with the exception of full free-form expressions and statically typed pointers and references, RPG IV fulfills all of these requirements and adds %BIFs for such things as file status indications; rounding and editing of diverse numeric types; string manipulation and conversion functions; manipulation functions for time, date, and timestamp data types; etc.

What Is Lacking in the RPG IV Language?

For the RPG IV language to properly evolve and fulfill its niche as an integration language, statically typed pointers and references, for ADTs as well as for primitives, absolutely must be at the top of the list of things the developers at Rochester need to pay particularly close attention to. While static type checking by the compiler is accomplished on function prototypes for primitives (except with length on character fields), such checking is lacking on pointers and references to variables of a data structure type. Statically typed pointers and references are important both for elimination of runtime errors in arguments passing (shifting responsibility to the compiler to catch invalid arguments) and for proper function signature resolution (better granularity) should function overloading be added. For example, you have probably experienced the problem of either passing a parameter on a program call that was longer than that expected by the called program or passing parameters in the wrong order. Unpredictable runtime results usually occur. A similar situation arises when you pass a basing pointer to a called function that uses it for a structure (ADT variable) that does not match the structure it is based on.

Why Is Static Type Checking So Important?

The code in Figure 1 demonstrates the current deficiencies in static type checking in RPG IV, as compared to C. In the example, an ADT called Address (A in Figure 1) has been defined with the typical subfields of name, address lines 1 and 2, city, state, and ZIP. Additionally, another ADT named Bogus (C in Figure 1) has been defined with distinctly different content that's more representative of an item in inventory, with subfields such as item, on-hand quantity, and price.

Figure 1: Type checking in RPG IV

At B in Figure 1, two variables, myAddress and yourAddress, are declared to adopt the ADT structure of Address. Then, at E, they're initialized with appropriate values. Meanwhile, a variable called myBogusItem is declared to adopt the Bogus ADT at D and initialized with appropriate values for that data type at F. In each of these situations, after the variable has been initialized, a function called the printAddress() function (which takes a pointer, presumably to an Address ADT) is invoked. Yet, in G, you can clearly see that a pointer to myBogusItem is passed to the printAddress() function. This mistake is unfortunate but typical. The printAddress() function (H) uses the printf() C function to print the results to the display. This example compiles perfectly, but it fails to produce desirable results. So why didn't the compiler catch the mismatch of type?

Figure 2 shows the identical function coded in C.

Figure 2: Type checking in C

Once again, an ADT called Address has been defined to contain the typical subfields in the structure with name, address lines 1 and 2, city, state, and ZIP in A of Figure 2. Then, in B, Bogus has been defined just as it was in the Figure 1 RPG IV example--as an item in inventory. The two address variables, myAddress and yourAddress, are declared in C to adopt the structure of Address. The Bogus variable myBogusItem is also declared in C, as it was in the RPG IV example. In D, both myAddress and yourAddress are initialized identically as they were in the RPG IV example. In E, myBogusItem is initialized the same as it was in its RPG IV counterpart. As in the RPG IV example, a function named printAddress() has been declared and defined to take a pointer to an Address ADT and print the expected results (G of Figure 2). And once again, you can see in F that a pointer to myBogusItem has been inappropriately passed to that function. However, this time you get completely different results when you attempt to compile it.

Figure 3: C knows the difference in types pointed to

In Figure 3, you see that the C compiler rejects the statement in F of Figure 2 that attempts to pass a pointer to a Bogus ADT instead of a pointer to an Address ADT. This is a good example of static type checking, something RPG IV currently lacks and seriously needs in order to properly evolve.

In a somewhat perfect world, you would be able to define a print() function in different forms like the example shown in Figure 4: one for an Address ADT and another for a Bogus ADT.

Figure 4: Static casting in a perfect RPG world

You'd then define different procedure code to properly print the type being pointed to. This is the essence of function overloading, and it's what RPG IV needs. Given the new static_cast keyword (or something like it) and a type specified in parentheses, the compiler would be able to resolve the function name ambiguity by casting the pointer in a prototype to a particular data type (ADTs included). The compiler would then invoke the proper version of the print() function reflected by the type passed. Currently, the basing pointer simply points to a void* data type, meaning that it can point to anything. This is a fairly significant deficiency in the RPG IV type-checking system that must be corrected for RPG IV to move forward, and it was recognized as such by Bjarne Stroustrup in The Design and Evolution of C++ when he stated, "Allowing implicit conversions of void* to other pointer types would open a serious hole in the type system." Static type checking is a significant feature requirement for any language that contemplates OOPL attributes like function overloading. Stroustrup went on to say, "Static type checking was to me, after my experience with Simula and Algol68, a simple must...."

IBM can add all the %BIFs it wants, but until this flaw has been corrected, RPG IV will cease to be competitive and will eventually become a minor language even on the iSeries platform.

Function Overloading--What Is It and Why Does RPG IV Need It?

Ranked recently in an MC Press Online poll as seventh (in a three-way tie) out of 10 choices for new RPG features (receiving only 4% of the vote when this article went to press), parameters (or function) overloading can't get any respect from RPG programmers. Perhaps that's because, unless you're a Java or C++ programmer, you have heard the term but weren't quite sure what to make of it. Function overloading is usually discussed in the context of OOPLs but is equally applicable to procedural languages like RPG IV. It is also prerequisite to enhancing a procedural language to enable it for OO development, as it is capable of acting as an integrator between diverse, and often differently constructed, types (objects). As you have seen in this discussion so far, only OO languages typically implement function overloading, but as an integration language, it is critical for RPG IV to have this capability. While C has a static type checking system (but did not always), it does not implement function overloading, as shown both in the failed attempt to overload the print() function in Figure 5 and in the prototypes from the CNOOVRLD program written in C in the downloadable source with this article. C left that to its descendent, C++.

Figure 5: Failed attempt to overload print() in a C program (CNOOVRLD)

To give you an idea of the importance of function overloading in an OOPL, Figure 6 presents the same application you saw earlier in Figures 1 and 2, but Figure 6 presents it in Java to demonstrate function overloading.

Figure 6: Function overloading in Java

In the OverLoad class written in Java in Figure 6, you can see the Address ADT has been represented as a static inner class in A. (For the moment, don't worry about what static inner classes are--for purposes of this exercise, you are using them simply to reduce the number of source modules required to compile a functioning, self-contained application.) Additionally, you can see that it contains the data elements expected--a name, address lines 1 and 2, city, state and ZIP. Also note that two print() functions--one that takes no arguments (B) and one that takes a String argument containing a special_message (C)--have been defined for this class. The two print() functions can exist in the same class because of the signature differences and can be properly accessed by the compiler because of the function overloading feature built into Java.

Notice that the Bogus ADT has also been represented as a static inner class in D. Once again, this type (class) has been represented to be consistent with previous examples in this article, as an item in inventory with an item code, on-hand quantity, and price. The Bogus type has also been defined to include two print() functions--one that takes no arguments (E) and one that takes a double argument as a percentage markup on the price (F). This is another good example of function overloading in action--two functions with the same name but different signatures, co-existing in the same module or class.

The actual objects for these two classes are created in the main() body of the OverLoad class starting at G. At H and I, you can see the creation of the two Address ADT variables (objects), myAddress and yourAddress. Then, at J, you can see the creation of the Bogus ADT variable, myBogusItem. The objects are created using the new operator. (Note: If you refer to the C++ code, this is accomplished as a part of the variable declaration with an implicit call by the compiler to the constructor of each type, but it could also have been an explicit call to the new operator in C++.) You can see in H of Figure 6, myAddress.print() selects the address print() function that only prints the address, while in I, yourAddress.print("A special address for a special person...") opts to use the version of print() that prints a message as well as the address. In fact, it uses the base print() function that has no arguments to print the basic address information as shown in C. In J, you can also see that myBogusItem.print(1.5) selects its version of the print() function that calculates and prints an item with a marked-up price, once again calling the base print() function that has no arguments to print the basic inventory information as shown in F.

The function overload feature can also be seen as a valuable feature in C++. While I have included C++ source along with the other downloadable code with this article, it is not valuable to present it as another item for discussion here. However, you should examine the source, if only to acquaint yourself with how function overloading is defined and represented in C++.

Function overloading would not be possible (or certainly not safe) without the language having previously implemented a good static type-checking system to resolve function name ambiguity (to bind the proper function call at the appropriate places, usually using a name-mangling technique) and enable compile-time rather than runtime errors to be detected when the wrong type is passed to the a function (you saw this deficiency in the RPG IV example).

Who's in the Lead, C or RPG IV?

While it can be argued that C supports many %BIF functions currently in RPG IV, there are some that have no comparable equivalent in C. These %BIFs add an ease and elegance not supported in the C procedural language. Add to that the JNI wrapper support for Java in the form of the (O)bject data type in RPG IV, and RPG IV barely pulls out in front ahead of C in unique built-in features and interoperability, and some would argue, with better print file support (I would be remiss to not at least mention that). And while C has a stronger type checking system implemented than RPG, it does nothing significant with it until C++. In most of the other areas listed, RPG IV and C run neck and neck.

However, C++ (as a direct descendant of C) clearly eclipses RPG IV (as it should, being an OOPL) with function and operator overloading and true objects (data wrappered with function). Yet, most C++ compilers still support source written using standard C procedural syntax. This same strategy could be taken with RPG IV (ILE RPG). IBM could provide a version of the ILE RPG compiler that could be used to assemble code written in RPG++ (for example) for object-oriented applications, yet still support the procedural syntax of RPG IV. This would help bridge the semantic and conceptual gap that currently exists between procedural RPG developers and Java (or C++) developers.

From my perspective, the point is to learn OO design and analysis concepts (constructs and patterns), not any one particular OOPL. It is this knowledge that is transferable from one OOPL to another; makes OO programmers productive and efficient; and ensures OOPL projects meet time, features, and performance objectives. Otherwise, Java (or C++) is "just another language to learn." The skills you acquire can help you simply use the language or help you use the language well.

This knowledge would go far in helping to avoid costly mistakes that occur during the application design and early-implementation stages because of the lack of understanding of the design initiatives on one side or the other. And this is why IBM should roll forward (without delay) to an OO version of RPG. Just like the dinosaurs, RPG must evolve or fade into extinction. What's the alternative if RPG goes extinct?

I'd Like a Mocha, Light on the Espresso, Please

A new form of Java has been slowly entering the market that I like to call "JAVARG." It uses Java syntax with an RPG flavor, but without the (P)rocedural aspect (thus dropping the "P" from RPG). JAVARG is a strange animal in that it does not usually conform to the Sun-recommended naming conventions (so you are likely to see all uppercase-named objects, such as MYJOBQ, instead of myJobq) and uses opcode methods like MYFILE.CHAIN() to retrieve data from an iSeries server, while under the hood actually using SQL SELECT to get the data. In so doing, JAVARG has, and rightly so, earned frowns and scorn from real Java programmers. The tools used in conjunction with JAVARG (RPG/400-to-Java translators and cut-and-paste IDEs) attempt to keep the programmer insulated from the true OO nature of Java by turning them into business rules writers rather than earnestly helping them make the switch to Java.

There will quite likely be a need for JAVARG programmers in iSeries organizations that are happy with the business analytical skills of their RPG staff and do not have the resources to train a new staff of Java developers in industry-specific knowledge. Their business worth is more valuable to these organizations, which are not in the software business, than pure technical talent. You just need to decide if JAVARG is for you and become familiar with the limitations it imposes.

Power and Sleek Design

You probably never thought you'd hear the words "power" and "sleek design" used to describe the RPG language. However, if IBM moves the language to the next evolutionary step and makes RPG IV the premier integration language of choice on the iSeries platform, software artisans would be challenged to take another look at the new and improved RPG language.

Why evolve? Why not? This next logical step for RPG IV plugs a long-standing type safety hole. And languages other than RPG IV (C, for example) have taken on the OOPL challenge and succeeded. There is ample documentation on the problems you must overcome to reach your destination, and there's a roadmap on how to get there (OOPL) from here (procedural language). Let's give the developers at Rochester an interesting challenge rather than just another %BIF to implement. Move parameters (function) overloading to the top of your wish list and tell IBM to hurry! You can't wait until next Christmas!

Jim D. Barnes is a freelance writer and Systems Engineer in Plano, Texas. Jim can be reached at This email address is being protected from spambots. You need JavaScript enabled to view it..