Jon here, back again with the sixth and final episode in this journey through the history of RPG IV. I must say I have enjoyed writing these pieces - they bought back fond memories and of course a few not-so-fond ones!
Before starting into the topics I mentioned at the end of Part 5, I will just quickly mention one possible update to RPG IV that has not yet been formally announced.
So how do we know about it if IBM has not announced it? Well IBM recently began shipping version 9.5 of RDi (Rational Developer for i) and in doing so let the cat out of the bag a few days early in terms of the next RPG IV announcement. RDi 9.5 includes RPG features that allow free-form coding to start in position 1 and continue to position whatever ... no more columnar restrictions! To say that this news was greeted warmly by many in the RDi community would be to put it mildly. The official announcement happened this morning.
With this enhancement, coupled with the V7 free-form file and data declaration support, RPG can truly claim to be a fully free-form language. Sure you can't code I-specs and O-specs in free form, and probably never will be able to. But there is no reason to write new programs that use them anyway.
I no longer work for IBM, so I don't have any special insights into their plans for the future of RPG. But that doesn't stop me from postulating a few possibilities that we might see added to the language. One thing that I'm fairly sure won't be added is Object Orientation. There have been some requests for it over the years, but it would be really difficult to do a good job while maintaining compatibility and I suspect the number of potential users is low. We have excellent OO-based languages like Java, C++, PHP, and now Python and node.js available to us on the platform - it doesn't make a lot of sense to try to retrofit RPG with OO features.
Not that there aren't some OO-like features that would be worth "stealing." For example, it would nice to be able to define multiple routines with the same name but different parameters, with the compiler working out which one to call based on its signature (i.e., the number, type and sequence of parameters).
Another useful option that could be used to similar effect is for RPG to implement typeless parameters. In other words, you could pass anything. The called routine would determine its action based on the type of the actual parameters that were passed. The biggest problem with this approach is that the OS does not provide full parameter descriptor support. Only specific data types are covered. As a result the utility of this option would either be restricted to those data types, or RPG would have to invent its own descriptor system.
Both of these features have been requested a number of times - we'll have to wait and see if either of them rise to the top of IBM's To-Do list.
Perhaps the types of features that stand the best chance of implementation are those that simplify common business functions. For example, a mechanism to simplify the testing of whether a field value is in a certain range. Or perhaps one to determine if the value of a field exists in a specified list - similar to SQL's IN (list of values).
These could be implemented as BIFs or in a similar fashion to the way COBOL does it (I'm talking about 88 levels for the bilingual among you) where the valid values/ranges are set up as part of the data declarations. Of course, courtesy of subprocedures, you can already implement such functionality yourself - but having it in the language would benefit even the ILE-phobic among our brethren.
Other likely candidates are those where there is a "gap" in the existing support. For example, we have had DS arrays for some time now, but only basic %Lookup operations can be performed on them. You cannot use the GT, LE, etc. variants - assumedly because you can't specify Ascend/Descend on an individual key. Personally I'd also like to see functions such as %Lookup and %Scan be capable of returning an array as the result when used in an assignment.
While I'm talking about arrays ... using PHP has made me lust for more powerful array support in RPG. For a start, a variable length array would be nice. I know there are some implementation issues due to legacy features of RPG, but I still think it could be done and would be a worthwhile enhancement. Along with this, of course, should come an extension to the FOR operation to support some form of FOR-EACH for simple loop traversal. It is amazing how much simpler and cleaner your logic can become when you can do away with loop counters and simply say "Do this to all of them." If IBM was also to enable SQL to populate dynamic arrays, you would also have a nice simple way to traverse result sets.
I could go on and on - but hopefully we'll see some suggestions from you readers in the blog comments section.
I hope you have enjoyed reading this series as much as I have enjoyed writing it. Looking back over the past 25 or so years has been fascinating and I hope I've been able to bring you all a little better understanding of the amount of work that goes into many of the decisions at IBM that result in the products you use every day.
I'm very proud of having been a part of the team that "gave birth" to RPG IV. I'm even more proud to be able to still call "friend" many of the dedicated team at IBM who continue to enhance the language we all love. In particular, I have to single out the delightful Barbara Morris - Queen of RPG IV - and the person behind many of the recent enhancements to the language.
Did we make mistakes? Sure we did, but we also got a lot right. When I see some of the amazing RPG-based tools and applications out there today, I know we did the right thing in fighting to produce a compiler that opened the door to capabilities that were unimaginable for an RPG programmer 21 years ago. I'm also sure that RPG IV has the legs to be around for another 21 years - although I may not still be around for that celebration!
P.S. At the end of Part 5, I said I would talk about RPG's underutilized Open Access feature. I may return to that in the future, but when I actually got round to writing this piece it just didn't seem to "fit." My apologies to anyone who was holding their breath waiting for that.