This originally appeared as a post in our (now inactive) blog called iDevelop published on IBM Systems Media.
At the end of the previous episode of this saga, I mentioned that in this blog entry I would explain why the No. 1 outstanding user request (parameters for subroutines) was never implemented. So here's the story as best I remember it.
When I first received details of the design for implementing this feature, I was pleased to see that the developers had included, as an option, the ability to define subprocedures (i.e., functions) with return values because a feature like that made so much more sense than parameters to subroutines, which really did nothing to excite me. Full-blown functions provided not just parameters but local variable support not to mention recursive calls, for those rare occasions that required them. Of course the capability for the resulting routines to be included in Service Programs was a major advantage. That would help to avoid the awful practice of code cloning that was typical of so many RPG shops. I really hated that practice.
In my mind, while providing parameters to subroutines would at least mean it would be possible to use a /COPY to include standard routines, it really didn't move the language forward. To me it was a no-brainer to go with the full subprocedure support.
So when I was called into a meeting with the development team one day I was amazed to find that subroutine parameters had been designated as the preferred solution. To say that I was surprised is to put it mildly. After hearing a few discussion points pro and con, I informed the development manager that if he went ahead with that decision that I would non-concur with the proposal. In those days the IBM development process required sign-off at all levels in the management chain--and that included me. Knowing that overruling my objection would slow his development plans down, the manager turned to his senior developers and asked them to explain why I was wrong and that the full solution would be much more expensive to implement, etc. He clearly expected that they would agree with him and get me on-side. They didn't. For each argument he made they pointed out that there was no advantage in his approach and made it obvious that they really wanted to implement subprocedures.
It turned out that, unknown to me, the manager was new to development and knew very little about programming. As a result, he had taken the user request for subroutine parameters very literally and in his determination to fulfill it had ridden roughshod over his developers. They in turn had partially caved in, not wanting to get into a fight with their new manager. Once somebody outside the team took their view they were happy to return to their original positions.
The implementation of subprocedures led in turn to the development of the prototypes. And that in turn opened the door to the use of C functions in RPG.
It might surprise you to know that that "feature" was not planned. I won't say that nobody had ever thought of the possibility, but it was certainly not mentioned in any design documents that I read. To the best of my knowledge the first time that a C function was ever used in RPG came about when I was trying to find a solution for a customer who needed a new random number generator. He had been using code that was included in the original IBM version of QUSRTOOL. The problem was that his new super-fast system was generating duplicate "random" numbers and making a complete mess of his system. I knew there was a rand function in the C library and in thinking about how to make it available to him (he didn't have the C compiler) wondered if it could not be used in RPG via prototypes and the EXTPROC keyword. A quick trip down the corridor to Barbara Morris' office, a minute or two of her fingers flying over the keyboard, and we had a working prototype!
We subsequently did some additional research on the limitations of our approach and I subsequently presented a session on using C functions in RPG to a standing-room only crowd at COMMON. One limitation, and really the only significant one, that we discovered was that the way in which floating point values were passed by the system meant that they could not be "faked out" by substituting character fields. Because many C library functions used floating point variables that was a problem. So, those of you who wondered why, back in V3R7, IBM added floating point variables to RPG now know the answer. We needed them to make the full range of C library functions available.
So successful was the capability to integrate C functions that subsequently RPG added the capability to prototype and call Java methods. The range of additional functionality subsequently made available to the RPG community by these two simple changes is enormous. From integrating Web services to building Excel spreadsheets, RPG has in recent years been used for tasks well beyond what any of us could have imagined when this journey began.
Next time, in the sixth episode I'll talk briefly about an RPG feature that I still consider sadly under-utilized (Open Access) and where RPG may go--and probably won't go--in the future.