Top 5 Features RPG IV Needs Now

As one of the original advocates for IBM to enhance RPG back in the 1980s, I continue to offer my advice to them in an open forum so that they and others can provide feedback to my suggestions to help improve the language. Many of my suggestions have been implemented, from the CAT opcode to the %CHAR built-in function, to the EXTFILE keywords. Likewise on at least two occasions, IBM has solicited my advice on an enhancement they were thinking of adding to RPG IV and accepted my suggestions, the EVALR opcode and the %FIELDS built-in.

But those aside, I continue to offer a set of suggestions every two years that I call my Top 5 Features RPG IV Needs Now, and here are this year's candidates. I'd like to invite my readers to offer up their practical suggestions for enhancing RPG IV. Use the Comment's area at the bottom of the article to post your feedback on these suggestions or post you own Top Five.

1. Consistency

Please implement future enhancements in a consistent manner. It is getting to the point where teaching RPG IV means you have to often say "In this situation you do it this way, but in this situation you do it that way, but in this other situation you do it another way" --how disappointing. The good news is that lately IBM seems to be more consistent with new features, with one huge exception: thread support. There are what, three different keywords/syntaxes to indicate something is being used in a multithread environment.

.....H.Functions+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
     H THREAD(*CONCURRENT)

.....PName+++++++++++..B...................Functions++++++++++++++++++++++++++++
     D myproc          B                   Export SERIALIZE
     
.....DName+++++++++++EUDSFrom+++To+++++TDc.Functions++++++++++++++++++++++++++++
     D myLocalVar      S             10i 0 STATIC(*ALLTHREAD)

• THREAD(*CONCURRENT) Indicates that the program can be run in a multi-threaded environment and in multiple threads
• SERIALIZE on the P specification of a subprocedure indicates that when the subprocedure is used in a multi-threaded job, one instance of this subprocedure is shared between all the threads of that job. Without it, each thread has its own instance of the subprocedure.
• STATIC(*ALLTHREAD) means that all threads of a multi-threaded job that call the subprocedure use the same copy of the variable. It's a shared variable between threads.

If you learn and understand these concepts, then you realize why they were named as they are. But since all this multithreaded stuff is new to most RPG IV programmers, a more consistent naming convention could have been considered. Perhaps something such as:

.....H.Functions+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
     H THREAD(*CONCURRENT)

.....PName+++++++++++..B...................Functions++++++++++++++++++++++++++++
     D myproc          B                   Export Thread(*shared)
     
.....DName+++++++++++EUDSFrom+++To+++++TDc.Functions++++++++++++++++++++++++++++
     D myLocalVar      S             10i 0 STATIC Thread(*shared)

If THREAD(*SERIALIZE) would be better than my THREAD(*SHARED) keyword, I'm okay with that—it's the consistency I'm looking for.

2. %DAYOFWEEK and Friends Functions

There are several built-in APIs that begin with the letters "CEE" that are classified by IBM as "Built-ins." This typically means that if you call the built-in directly from your RPG IV code, the built-in's code is copied into your program object instead of evoking a call to a subprocedure or subprogram. Sort of like an object code version of /COPY. That's cool, but there's several built-ins out there that we still don't have access to via a built-in function. Why doesn't RPG have a "get day of week" function? Why doesn't RPG have a "write to the job log" function? Why doesn't RPG have a send-program-message function?

      /free
            day = %getdayweek(%date());
            dayname = %getdayname(%date());
            realDateField = %date(myDateField : varName);
      /end-free

And you wanna tell me why we can't use a variable name for the Date Format code? What is this, 1984?

3. Native ASCII to EBCDIC to ASCII Conversion Support

Okay, if I have to call iconv() one more time... The iconv() API is too complex for most RPG IV programmers who don't know how to call it correctly, so they have to look around for example code and hope it works. But that's only after days, weeks, or maybe even months of asking around. The ones who have a real problem are those who give up and use the long-since obsolete QDCXLATE API, which doesn't work in all situations, and even IBM suggests "should be avoided in favor of iconv." When will IBM add %ToASCII() or similar to the RPG IV language? It's getting embarrassing showing people the 40+ lines of code they need to do a simple EBCDIC-to-ASCII conversion.

4. Ignore the Record Format

Ninety-five to 99.5 percent of all code being written today uses single-format database files. So why should I care if the record format name is the same as the database file? SQL doesn't care. If IBM would really get rid of all references to record format names/IDs in RPG IV, that would be a wonderful thing. Oh, and if you're listening IBM, if you ever do an "RPG V," don't support the RPG Cycle or multi-format database files--keep them back in RPG II where they belong.

5. Release Independence

A program that I create should not depend on a version of i5/OS (IBM "i") in order to run. If I'm on v5.4 and use XML-INTO, then that program should run on V5.1 and later. There are so many little features added in each "point release" that nobody can keep track anymore. It makes RPG IV difficult to teach, and keeps people from using new feature even if they can, simply because they don't know that they can use them. Often a shop is running v5.4 but has multiple boxes installed and has to compile to v5.2 (for example). But if you're compiling on v5.4 and you learn about this cool XML-INTO opcode (and this is just one of hundreds of example situations) and go to use it, guess what? You can't compile your program because your compile is probable set up to default to TGTRLS(*V5R2M0), which doesn't support XML-INTO.

The reasons for this restriction have been explained to be time and time again by folks who think the reasons for the restriction mean something. They do not. If IBM does one new thing to RPG IV in version 6 release 2, it should be to make any new feature of v6.2 backwards compatible with v6.1. Specifically, if IBM adds a %TOASCII() built-in function in order to compile a program that contains a call to %TOASCII() you will need to be on v6.2, that's fine with me. But to run and use that program, I should not be required to be on v6.2, but v6.1 or later. Try teaching RPG to people in a shop running multiple releases--they spend a lot of time being frustrated because they have (for example) XML-INTO but can't use it yet.

More to Follow

There are obviously more than five suggestions that could make a list like this: native IFS I/O, built-in CGI support, built-in support for modern file formats such as MS Excel, PDF, TIF and XML come to mind. But what do you think? Add a comment to this article at the bottom of the page. If that link doesn't work, you can also post your comments in this thread in the RPG World discussion forum. We'll discussion some of the comments in Friday's RPG World Live show at 11:00 AM central (16:00 GMT) on Friday September 5.

Bob Cozzi lectures on RPG IV and System i development at corporate customers and user groups all year long. He is author of "RPG TnT: 101 Dynamic Tips 'n Techniques with RPG IV" and hosts RPG World Live, a video podcast for RPG developers and Managers aired live on Fridays from 11:00 AM to Noon Central time (16:00 GMT) on ustream.tv and on RPGWorld.com. Bob also produces RPG World, the most popular RPG IV developer conference of the year. Visit RPGWorld.com for details on the dates and location of the 2009 RPG World Conference.