Re: Benefits of Sub-procedures -- RPG400-L

Bob Cagle wrote:

I'm looking for some ammo, guys!

I personally have been using RPGIV and sub-procedures, service programs,
etc. since '96.  But I am running into an ever increasing number of
programmers that ask the basic question "Why use a sub-procedure when it
does the same thing as a program call?"

I always spout the performance benefits, plus the ability to call a
procedure from within an expression and return a value.  But even then
it sometimes isn't enough to convince them.

Can anyone give me some more compelling reasons for switching completely
to ILE RPGIV?  Remember, these are typical business programmers and
statements like "it's cool/fun/looks & works like java/etc." is just
even more of a turnoff for them.  I'm looking to give some sound
business reasons for the change.

Bob: You could always wait out the few months until those naysayers retire!

Others have provided good arguments. But I just can't resist joining in this thread.

For those of us who have used programming languages other than RPG III, the issue is a real no-brainer. Procedures (and their close siblings, functions and methods) are probably the most commonly used control structure in most other programming languages. That's even more true now with OO languages, where programs contain classes with multiple small methods. And so you could use other programming languages to demonstrate how antiquated a non-procedure view of programming is.

But I have a feeling that argument will simply cause the naysayers to dig in their heels more. ;-)

Okay, let's try something more tangible. Some of these dinosaurs probably remember RPG III programming on the S/38. In those days, modular programming was the "in" thing. It was generally encouraged to write numerous small programs, each doing one particular thing. Unfortunately, this strategy had negative performance implications on the S/38, and so had to be tempered somewhat. The trick was to find a balance between nicely modularized programs and good performance. Now enter procedures: It is now possible to implement the nice modularized programs we all knew we should write, but using static binding in ILE RPG IV, the performance penalty is gone. Now, there's no good excuse not to write neat and tidy, well-modularized code.

Oh yeah, one more thing: Do your applications contain program names like "HDGI0034" and "X01UPDTSL"? Might the dinosaurs accept the argument that using procedure names like "DisplayOrderEntryScreen" and "UpdateSalesLedger" might very well provide some productivity improvements? Or would that be considered too "cool"?

(This goes back to my old argument that many programmers don't want programming to be easy. If programming is hard, then their high salaries are justified, eh?)


p.s. And I have tried arguing easier maintenance - which they will
always argue that pure ILE RPGIV is harder to maintain because of the
increased number of objects and source members to keep track of!

Huh? If anything, with pure RPG IV, you should have fewer source members to take care of, if you code multiple related procedures in each module.

Good luck!

Hans