I never thought I'd see the day when I felt that IBM needed to slow down its development of RPG IV, but that day has come.

All the traditional languages--such as COBOL, FORTAN, and PL/I--have had enhancements added to them. However, enhancements to those languages have been done on a scheduled basis. Enhancements were planned on a periodic basis and were based on public comment.

RPG, on the other hand, had few enhancements between the early 1970s and the mid-1990s when RPG IV was shipped. Sure RPG III was "better" than RPG II, which led to wide use of RPG, but there weren't significantly new features added to the language itself.

But since 1994, RPG IV has been enhanced in nearly every other release of OS/400. Today, RPG IV is being enhanced in consecutive releases of OS/400.

The problem is that this development schedule is both fragmenting the OS/400 (iSeries and AS/400) application development community and giving the technical trade press the ability to publish code fragments that people are not able to use.

For example, within the RPG community, the use of the OS/400 Version 5 /FREE (free-format) RPG is relatively insignificant. Yet you see it frequently illustrated in trade publications. This is, of course, because it is new; to some people, continuing to write about "older" code or language syntax is boring.

What is wrong, in my view, is that enhancing RPG IV with each new release is creating incompatibility within the OS/400 community. For example, if I were to publish a procedure in RPG IV that utilized the /FREE syntax, it would be useless to about 85% of the iSeries marketplace (254,000 iSeries customers with about 35,000 installations of V5R1). If I write a piece of code that utilizes a V5R1 built-in function, that code cannot be used on V4R5 or earlier. Again, nearly 85% of the RPG IV users out there would not be able to take advantage of it.

Adding new features to each release of OS/400 has become counterproductive. Many of the new features in RPG IV are inconsistent with previous features. This situation has created an environment in which learning those new features has become complex--not to mention teaching them. Don't get me wrong; we can still teach RPG just fine, but it is downright embarrassing to have to illustrate the inconsistencies between versions.

Here's an example, and although I've talked with the RPG developers about this, the following problem is too confusing. The new %KDS built-in function was created to allow the use of data structure subfields as key fields on the CHAIN operation code. So now there are three distinct free-format syntaxes for the CHAIN operation, in addition to the traditional fixed-format CHAIN opcode (four in all). Here are the three free-format syntaxes:

1. CHAIN keylist myFile allows you to CHAIN to a file using a traditional key list or a single field that matches the key of the file. The key list must be declared with the fixed-format KLIST and KFLD opcodes.
2. CHAIN (field1, field2, field3) myFile allows you to CHAIN to a file using any fields as an ad hoc key list. These fields must be enclosed in parentheses.
3. CHAIN %KDS(data-structure) myFile allows you to CHAIN to a file using the subfields of a data structure by enclosing the data structure name in the %KDS built-in function. This is new with V5R2.

So in the first context, you just specify the key value; in the second, you specify the key value enclosed in parentheses; in the third, you need to enclose the key value in a built-in function.

Previous to free-format, you simply read the syntax diagram for the CHAIN opcode and you were done. Today, special conditions apply to each of these three new syntaxes, so selecting the correct syntax is no longer a no-brainer.

Another example is the UPDATE operation code. In V5R2, IBM added a feature that allows you to update a select group of fields. The WRITE operation code (which has a similar structure) did not receive that field selection capability. IBM has said this functionality will be available in a future release of RPG, but that just means another level of inconsistency. If you're on V5R2, you can use this new feature on the UPDATE opcode but not on the WRITE opcode. Then, when you upgrade to V5Rx, both UPDATE and WRITE will support the new feature. It is getting very frustrating.

The quintessential example is the roll-out of the compiler directives for conditional compiling. When they were introduced in V3R7, they did not allow you to, for example, check which release of OS/400 was being targeted with the compiler. In a later release of OS/400, IBM introduced that functionality, but, of course, it wasn't backward-compatible, so it was of little value to targeting a previous release with conditional compiling. In the casual, unscientific surveys I do when I teach RPG IV, I have found a total of two people using compiler directives. (I guess that makes three if you count me.)

These are just a few of the many areas in which unnecessary complexity has been introduced into the language in recent years. By fragmenting the delivery of new features, IBM is creating incompatibility.

What's the Solution?

The solution to this problem is, in a word, planning. IBM needs to plan timely releases (i.e., enhancements) to RPG IV on a scheduled basis, not on an OS/400-release-level basis. It is my belief that IBM needs to do the following:

• Schedule releases of RPG IV (or "RPG V") on a periodic basis, such as a 3- to 4-year cycle--regardless of the OS/400 version or release schedule--and include much more complete features in those releases.
• Design enhancements for RPG and then publish a request for comments (RFC) on those enhancements far enough in advance of the release so that public comments can be considered.

By coming out with new releases of RPG every few years--as opposed to every OS/400 release or two--IBM will help stabilize the language and encourage consistency.

Hurrying through the development cycle to match the OS/400 cycle is not the most beneficial development methodology. Instead, IBM should be designing releases with complete, consistent, important features and allowing public comment on those features and their design. After all, that technique has been proven time and time again.