On Tue, Jun 28, 2011 at 10:58 AM, Buck <kc2hiz@xxxxxxxxx> wrote:
I think some clarity would be added to the conversation if we
made the distinction between RPG IV syntax and modern thinking.
I have been trying to make this distinction the whole time. My
contention is that it is much faster for me, personally, to apply
modern thinking to OPM programs (making use of the non-ILE
enhancements provided by RPG IV) than it is for me to use the explicit
ILE features of RPG IV.
I believe that a programmer using modern software
engineering principles would find it painful to write
code that doesn't use local variables
I do find it painful to do without local variables. However, I
personally find it *more* painful to jump through the hoops of
declaring my local variables... TWICE... than it is to just pick a
naming convention that prevents collisions. (And again non-ILE RPG IV
helps with this too, with the longer names and prefix feature and so
forth.)
Why make my life difficult if I already paid for RPG IV and WDSC?
I already make very good use of the non-ILE features of RPG IV. It
has paid tremendous dividends. I do not have WDSC installed, and as I
mention in another post, I am not completely sure I have a machine
suitable for running it. (This is assuming that WDSC was included
when we bought our AS/400, which I think you are implying. If it
costs something extra, then that's another option out the window.)
On Tue, Jun 28, 2011 at 1:36 PM, <paultherrien@xxxxxxxxxxxxxxxxxx> wrote:
I want to be sure I understand. When you say 'boilerplate' I understand you
to mean reusing the same code over and over again.
Not exactly. You are absolutely correct that "boilerplate" often
implies that. But in my case, I'm mainly complaining about the double
prototypes required for procedures. (Keep in mind I am on V5R2 if
that makes a difference.) Then, if I want to use some other module, I
have to jump through some additional hoops to link it in. I'm not
just referring to the additional declarations in the source, but also
the additional compilation steps. With my OPM style of development
(which happens to be very modular, mind you), I always just pick
option 14 from PDM (CRTBNDPGM). Yes, it's up to me to manage the
*ENTRY parms, but I personally find this quicker and easier than
managing prototypes and proper ILE modules.
So I guess what might provide further enticement for me to use genuine
ILE features is for the development environment to be able to put all
those declarations in for me, or make it very easy for me to do so,
without making *me* find and copy them. Or for the compiler/linker to
just be smarter and not require so much verbosity and/or separate
commands. For example, I would be much more inclined to create
service programs if I could just put some kind of directive in the
source that says "this is a service program" and then always just keep
using the same PDM option regardless of what type of compiled beast I
was creating.
I am tempted to explain about re-usable modules and service programs, but I
know you already understand about these too.
I know I must sound like an idiot to those of you used to making
proper ILE modules. But really and truly, I love modular design, and
I design modularly... in OPM. I just use standalone programs and
*ENTRY parms instead of modules and service programs. And for me,
personally, this is much, much faster than doing it the ILE way.
Plus, if there is an OPM pseudomodule called by dozens or hundreds of
existing OPM programs, I can extend the functionality of that single
OPM pseudomodule, accessible via new *ENTRY parms. I don't break any
of the existing programs, and I only have to modify those that I
choose to make use of the new parms. As I understand it, I cannot
convert that lynchpin, used-by-everybody pseudomodule to a proper ILE
module/service program without having to fix ALL of those dozens or
hundreds of OPM-style calling programs. (Even if they are already RPG
IV!)
So please understand I will never go back to RPG III. But right now,
where I work, with our existing codebase and tools, (RPG IV syntax,
BIFs, and limit increases) -> (huge benefits, practically zero costs),
while (ILE features) -> (not dramatic benefits, but significant
costs).
John Y.
midrange.com
