On Tuesday at COMMON in Chicago last week, I attended George Farr's session titled “IBM's Investment in RPG IV: Past, Present and Future”. The presentation had two very strong messages that should be welcome to those of us who make our living on RPG programming. These messages are: RPG is not a dead language, and IBM wants your input on RPG's future. The entire second half of the presentation was devoted to ideas that IBM has for new functionality in RPG. The question I had at the end of it all was, are these the best directions for RPG? Did IBM get it right?

To let you judge for yourself, I will list the ideas that Farr presented for RPG IV. All of these ideas are theoretical. It's important to understand that IBM has not made any decisions regarding these ideas, so they may never actually appear in the language.

CONDITIONS TO ITER AND LEAVE
These opcodes would be given conditions so that they would only execute if the condition is true, saving you from having to code a separate IF statement.

My opinion: This is a good idea, but all it does is save us two lines of code, so it's not a big deal.

EVALUATE CORRESPONDING
This would be a new opcode called EVAL-CORR that copies fields from one data structure to another. The fields would be copied by name. For example, suppose you have two data structures. Each structure has many different fields, but the only ones that they have in common are called NAME, CITY, and STATE. The EVAL-CORR opcode would copy just those fields from one structure to another, so that NAME is assigned to NAME, CITY is assigned to CITY, and STATE is assigned to STATE.

My opinion: This would be a big time saver, but I'd call the opcode EVALC or maybe just CORR instead of the longer EVAL-CORR. I'd definitely prefer to avoid having a punctuation symbol in an opcode name!

BASIS FOR LIKE & LIKEDS
This would provide a method of specifying that a variable or data structure declared on a D-spec is only a template. You can't use the variable itself, you can only use it as the parameter for the LIKE and LIKEDS D-spec keywords.

It would be possible to set the initial value of these fields so that you can use INZ(*LIKEDS) when you use LIKEDS.

My opinion: This is a great idea, and I'd very much like to see it as soon as possible!

ALLOW MORE THAN 80 COLUMNS IN SOURCE CODE
Right now, the compiler stops reading RPG source after column 80. Many people use this area for comments. Farr's proposal is to add a new H-spec keyword that lets you specify how many columns you want it to read before stopping.

My opinion: Not a bad idea, but it would rank very low on my priority list.

ALLOW %FIELDS BIF TO BE USED WITH OTHER OPCODES Currently the %fields BIF lets you specify which fields are updated when you use the UPDATE opcode in free format. This enhancement would add the ability to use %fields on other opcodes, such as READ, CHAIN and WRITE.

My opinion: Good idea.

EVALUATE WITH OVERLAY, EVAL(O)
This would stop EVAL from padding the result with blanks when data is assigned to a variable. If the length of the result doesn't fill the entire variable, the rest of the variable keeps its previous value. This is similar to what happens now when you use the MOVE opcode.

My opinion: This doesn't interest me. I can already do this with the %subst BIF if I really want to, but this almost never comes up.

FULL SUPPORT FOR NULL DATABASE FIELDS
The null indicator would be copied with the field when its value is assigned to another variable with EVAL.

My opinion: This should've been done in the first place.

SUPPORT FOR XML PARSING
A native XML parser built into RPG.

My opinion: XML will continue to grow in importance to all businesses. RPG need not only support XML, but also support other stream-file formats such as CSV, tab delimited, and XLS.

PROCEDURE OVERLOADING
The ability to have different subprocedures with the same names, but different parameter lists. The parameter list, in addition to the subprocedure name, would be used to determine which subprocedure gets called.

My opinion: A good idea, but not important to me. Using a different name for each subprocedure isn't that big of a burden. (However, I know that there are many RPG programmers who disagree with me on this point.)

SUPPORT FOR ALIASES
When a database is created through SQL, you can supply longer field names as aliases for the 10-character names. This enhancement would allow RPG to use those longer names in addition to the shorter ones.

My opinion: Sounds good to me.

TOOLING WIZARDS Wizards that would help you
modularize and modernize your RPG code. They would not simply convert the code for you, since this is often impossible, but would assist you by asking you questions and helping you fill in the updated code.

My opinion: It depends on how well this is implemented. A poor implementation would be more of a headache than it's worth, but a good one could help a lot of people.

NEW EXJSP OPCODE
An opcode that's similar to EXFMT, except that it would interface to a Java Server Page (JSP) instead of a 5250 screen. This would enable simpler integration of RPG and WebSphere.

My opinion: Bad idea. I work for a small business, and have no interest whatsoever in running WebSphere. Java and WebSphere are CPU and resource hogs. Give us a native, powerful Web interface like CGIDEV2, or make this option generic enough that it'll work with anything, rather than being limited to a JSP.

CONCLUSION
There are some ideas on this list that I don't agree with. In particular, the EXJSP idea frustrates me. I was just beginning to believe that IBM is no longer trying to move us away from RPG and towards Java, and they start suggesting that if we want a GUI, we have to use JSP?

I also believe that there are some important things that Farr didn't provide as a suggestion, and I will e-mail him to see what he thinks of my ideas.

On the whole, however, I think IBM is doing the right thing. In particular, showing us what they propose, and asking us for our input is the right thing to do. They want us to provide feedback to them, and on that score, IBM definitely has it right.

*Scott Klement is an iSeries NEWS technical editor. You can reach him at iSN@scottklement.com.